lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: get_property vs internal_get_property


From: Janek Warchoł
Subject: Re: get_property vs internal_get_property
Date: Tue, 19 Aug 2014 08:13:00 +0200

2014-08-18 10:44 GMT+02:00 David Kastrup <address@hidden>:
> Janek Warchoł <address@hidden> writes:
>
>> Hi,
>>
>> it's time to ask a n00b question and get the elephant (that was
>> bothering me for a couple years) out of the room: why do we have - and
>> use! - both get_property and internal_get_property?  We ought to use
>> get_property everywhere, right?
>
> Correct.  (internal_)get_property is analogous to
> (internal_)set_property, and at least instrumented_set_property can
> receive additional file/line number information for diagnostics from the
> set_property macro.

Hmm.  But it seems that get_property doesn't have any of this.

>> The more Lily code i read, the more i see that get_property is used
>> almost everywhere else...  Why not define get_property as a member of
>> the Grob class, too?
>
> Because it cannot be made to refer to file/line number information then
> or be used for instrumentation in a similar manner as set_property.

Do we actually use this regularly?  Or is it something that only
experienced devs use when they need to check something?

To me personally code readability has a very high priority, so what
about defining get_property as a member of the Grob class in master
branch, and keeping a debugging branch with all the fancy code like
this one?

I mean, all this cleverness makes it even more difficult to understand
lilypond code.

>> We are also converting property names from strings to symbols
>> everywhere - for example
>>
>> SCM meta = info.grob ()->internal_get_property (ly_symbol2scm ("meta"));
>>
>> What's the reason for that?
>
> Sloppiness?
> I see no compelling reason not to use
>
>     info.grob ()->get_property ("meta");
>
> here.

Hmm, bad example - here it's just sloppiness indeed.  I was actually
wondering why we wrap such stuff in ly_symbol2scm at all - why not
pass it as strings?  E.g. in

lily/pango-select.cc:105:  if (weight == ly_symbol2scm ("bold"))
lily/page-turn-engraver.cc:232:      if (command == ly_symbol2scm
("start-repeat"))
lily/slur.cc:286:  if (avoid != ly_symbol2scm ("outside")


> However, it's conceivable that any instrumentation of
> get_property would try recording the accessed grob type, and finding
> that might require looking in "meta".  So it's conceivable that some
> calls of internal_get_property that dig into internals of the grob
> rather than "regular" properties have been written using
> internal_grob_property in order to avoid useless info or infinite
> lookups.

Could you explain more?  I don't understand this well.


2014-08-18 10:50 GMT+02:00 David Kastrup <address@hidden>:
> Mike Solomon <address@hidden> writes:
>
>> On Aug 18, 2014, at 9:39 AM, Janek Warchoł <address@hidden> wrote:
>>> We are also converting property names from strings to symbols
>>> everywhere - for example
>>>
>>> SCM meta = info.grob ()->internal_get_property (ly_symbol2scm ("meta"));
>>>
>>> What's the reason for that?  And shouldn't we write all the C++ code
>>> so that it will automatically do the conversion, like get_property
>>> does?
>>
>> Entirely reasonable and good idea!
>
> If you take a look at the macro definition of ly_symbol2scm (which in
> turn is used in the macro definition of get_property), you'll find that
> it does per-invocation magic using __builtin_constant_p and memoization
> that cannot be done using C++.

Could you elaborate on why this would prevent us from doing what i suggested?

best,
Janek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]