Re: Naming question for get_property, set_property

[David Kastrup]

Dan Eble <address@hidden> writes:

> On Feb 10, 2020, at 17:47, David Kastrup <address@hidden> wrote:
>> It will look a bit redundant either way with
>> 
>> grob->Get (Grob, "color");
>> or
>> grob->grob_set ("stencil", SCM_BOOL_F);
>
> "Yuck" either way.  Removing "property" to shorten the name is not a
> good course of action.
>
> My brainstorming without knowing your reasons does not seem likely to
> help, but what the hey ...
>
>     grob->set<Grob_property> ("stencil", SCM_BOOL_F);
>
>     grob->set (Grob_property ("stencil"), SCM_BOOL_F);
>
>     grob->properties["stencil"] = SCM_BOOL_F; // Too much to ask?

Don't work.  It has to be a macro, and it has to know the type (so it
cannot figure it out by overloaded or something).  The reason is that
for a constant string, it executes code on the first run through that
translates that string into a Scheme symbol (this already happens) and
converts this symbol to an integer dependent on the general class
(Grob/Music/Stream_event) of the type.  Basically something like

({static int blurb = Type::lookup (property_name); blurb;})

This integer is then mapped to an index into a property array (rather
than a property alist).

But this memoization technique has to create individual code at each
call site (in order to be specific for each different constant string)
and thus cannot be the result of anything the compiler rather than the
preprocessor does.  Hence I need the preprocessor to be in knowledge of
the type.  Your proposals require the compiler.

Templating on a string constant is, unfortunately, not a thing at least
in C++11 (don't know whether they managed since then).  Or one could go
that route rather than GCC-specific in-expression use of a static
initializer.

-- 
David Kastrup