[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