Re: get_property vs internal_get_property

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> 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.

Not this in particular.  But it does wrap its argument in the the
ly_symbol2scm macro, and that can _only_ be done by a macro.  The
instrumentation is another consideration for set_property, but the
ly_symbol2scm wrapper is used for all get_* macros mapping to
internal_get_*.

> 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")

Because the lookup is not done using strings but symbols, and looking up
the symbol for _every_ call would be a huge waste of performance?

In Scheme, a symbol is represented by just a single unique integer, and
looking for them and comparing them for equality is fast.  Not so for
strings.  So one uses symbols for lookup rather than strings.

>> 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?

Not really.  I list _exactly_ what cannot be done using C++ (namely
per-invocation magic using __builtin_constant_p and memoization), tell
you where to find it and you ask me to elaborate why not being able to
do this in C++ would prevent us from, well, doing this in C++ via member
functions?

Sorry, but I _did_ elaborate.  If you don't understand what I am saying,
you will have to point out just _what_ you don't understand.  _After_
looking at the definition of ly_symbol2scm and checking for the details
I listed.  And, if you still don't understand, perhaps attempting to
code a replacement and see what problems this does or does not get you
into.

-- 
David Kastrup