Re: Naming question for get_property, set_property
Han-Wen Nienhuys writes:
> On Tue, Feb 11, 2020 at 10:17 PM David Kastrup wrote:
>
>> > the reason being that it is better if the source code looks like plain
>> C++,
>> > even though they might actually be macros that do advanced magic. Having
>> > normal looking source code helps editors and tooling (astyle,
>> clang-format)
>> > make sensible decisions.
>>
>> get_property (pointer, "property")
>> set_property (pointer, "property", value);
>>
>> would achieve that as well. Doesn't look like a member function, but
>> the thing looking like a member function also never actually was one.
>>
>>
> Earlier you said:
>
> "and for "reasons" I
> need to know the type, so the call would become something akin to"
>
> how does this work for the above?
decltype (*(pointer))
Basically the macro does not need to know the type by name, just in some
manner it can tell the compiler.
For the current syntax ->get_property ("property") I just have no
conceivable handle to get at the type of the pointer.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Re: Naming question for get_property, set_property
On Tue, Feb 11, 2020 at 10:17 PM David Kastrup wrote: > > the reason being that it is better if the source code looks like plain > C++, > > even though they might actually be macros that do advanced magic. Having > > normal looking source code helps editors and tooling (astyle, > clang-format) > > make sensible decisions. > > get_property (pointer, "property") > set_property (pointer, "property", value); > > would achieve that as well. Doesn't look like a member function, but > the thing looking like a member function also never actually was one. > > Earlier you said: "and for "reasons" I need to know the type, so the call would become something akin to" how does this work for the above? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Naming question for get_property, set_property
Han-Wen Nienhuys writes: > On Mon, Feb 10, 2020 at 11:48 PM David Kastrup wrote: > >> >> So for longterm efficiency reasons I am planning to reimplement the >> get_property/set_property macros and underlying data structures that map >> to get_property_internal/set_property_internal. They are currently used >> across a number of types in a sort of polymorphism, and for "reasons" I >> need to know the type, so the call would become something akin to >> >> I'm curious about your plans. Can you say more? > > >> get_property (Grob, "color"); >> or >> set_property (Grob, "stencil", SCM_BOOL_F); >> >> Now this is longer than before. Removing _property is not really an >> option since that lands us with std::set getting mapped to >> std::set_property_internal (or whatever). >> >> So Set and Get ? Or set_prop and get_prop ? Or Set_prop and Get_prop ? >> >> Or, since there are not all that many types to cater for, grob_set, >> grob_get, music_set, music_get, event_set, event_get (those obviously >> without the extra type argument) and what else I've been missing? >> > > I recommend simply reverting to what we had before I unified things, ie. > > get_grob_property > set_grob_property > get_music_property > .. etc. > > the reason being that it is better if the source code looks like plain C++, > even though they might actually be macros that do advanced magic. Having > normal looking source code helps editors and tooling (astyle, clang-format) > make sensible decisions. get_property (pointer, "property") set_property (pointer, "property", value); would achieve that as well. Doesn't look like a member function, but the thing looking like a member function also never actually was one. Your proposal certainly causes fewer headaches in the sed script department. It's just that many uses of get_property/set_property already lead to comparatively long lines. And Dan appeared to be no fan of what will end up in code like get_grob_property (grob, "property") since usually the name of the pointer already suggests the type. So I lean toward's the non-member-function-like variant. Let's see whether my sed-foo convinces me otherwise when I get there. -- David Kastrup My replies have a tendency to cause friction. To help mitigating damage, feel free to forward problematic posts to me adding a subject like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Re: Naming question for get_property, set_property
On Mon, Feb 10, 2020 at 11:48 PM David Kastrup wrote: > > So for longterm efficiency reasons I am planning to reimplement the > get_property/set_property macros and underlying data structures that map > to get_property_internal/set_property_internal. They are currently used > across a number of types in a sort of polymorphism, and for "reasons" I > need to know the type, so the call would become something akin to > > I'm curious about your plans. Can you say more? > get_property (Grob, "color"); > or > set_property (Grob, "stencil", SCM_BOOL_F); > > Now this is longer than before. Removing _property is not really an > option since that lands us with std::set getting mapped to > std::set_property_internal (or whatever). > > So Set and Get ? Or set_prop and get_prop ? Or Set_prop and Get_prop ? > > Or, since there are not all that many types to cater for, grob_set, > grob_get, music_set, music_get, event_set, event_get (those obviously > without the extra type argument) and what else I've been missing? > I recommend simply reverting to what we had before I unified things, ie. get_grob_property set_grob_property get_music_property .. etc. the reason being that it is better if the source code looks like plain C++, even though they might actually be macros that do advanced magic. Having normal looking source code helps editors and tooling (astyle, clang-format) make sensible decisions. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Naming question for get_property, set_property
Dan Eble writes:
> On Feb 10, 2020, at 20:48, David Kastrup wrote:
>>
>> 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.
>
> Well, constexpr enables some new and interesting things, though I
> imagine that having to interact with Guile nixes them.
For the purpose of generating a near-compile-time constant that would
not be a problem, static initialization to the win.
Like
template
SCM make_symbol ()
{
static SCM sym = scm_permanent_object (scm_string_to_symbol (symbol));
return sym;
}
which would generate one function per symbol that on its _first_ call
(when the Guile subsystem is already active) converts the symbol into
SCM and then memoizes it. But as far as I know, C++11 cannot template
on string constants (C or C++) like that. You need to create a named
character array or pointer and then can template on _that_ and that's a
lot more cumbersome in practice.
> Here, someone has figured out how to compute a CRC of a literal string
> at compile time: https://stackoverflow.com/a/9842857
We would not need anything that complicated.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Re: Naming question for get_property, set_property
On Feb 10, 2020, at 20:48, David Kastrup wrote: > > 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. Well, constexpr enables some new and interesting things, though I imagine that having to interact with Guile nixes them. Here, someone has figured out how to compute a CRC of a literal string at compile time: https://stackoverflow.com/a/9842857 — Dan
Re: Naming question for get_property, set_property
FWIW, python has getattr and setattr which would perhaps suggest get_prop(grob, "property") and set_prop(grob, "property", VALUE) I am not a fan of "arbitrary abbreviations" and get_property and set_property are only 4 characters longer. So maybe I would choose the latter (modulo your naming conventions w.r.t case) – just as one more data point, feel free to ignore it. Joram
Re: Naming question for get_property, set_property
On Feb 10, 2020, at 21:35, David Kastrup wrote: > property_set (grob, "stencil", SCM_BOOL_F); > > and > > property_get (grob, "color") These are fine. — Dan
Re: Naming question for get_property, set_property
David Kastrup writes:
> Dan Eble writes:
>
>> On Feb 10, 2020, at 17:47, David Kastrup 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 ("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).
Well...
property_set (grob, "stencil", SCM_BOOL_F);
and
property_get (grob, "color")
In that manner, the macro gets enough of a hold on the type of the
pointer to make this work. I'll not rule out that one can shimmy enough
of type madness around this to make
property (grob, "stencil") = SCM_BOOL_F;
work but I think that the payoff in relation for the complexity would
not likely be worth it.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Re: Naming question for get_property, set_property
Dan Eble writes:
> On Feb 10, 2020, at 17:47, David Kastrup 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 ("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
Re: Naming question for get_property, set_property
On Feb 10, 2020, at 17:47, David Kastrup 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 ("stencil", SCM_BOOL_F);
grob->set (Grob_property ("stencil"), SCM_BOOL_F);
grob->properties["stencil"] = SCM_BOOL_F; // Too much to ask?
—
Dan
