Naming question for get_property, set_property

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Naming question for get_property, set_property

David Kastrup

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

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?

It will look a bit redundant either way with

grob->Get (Grob, "color");
or
grob->grob_set ("stencil", SCM_BOOL_F);

The bulk of the replacement will be done by script, with manual cleanup
afterwards (some property names exist in more than one domain).  People
will still have to look at the source code afterwards without throwing
up, so what is your preference?

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

Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

Dan Eble
On Feb 10, 2020, at 17:47, David Kastrup <[hidden email]> 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?

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

David Kastrup
Dan Eble <[hidden email]> writes:

> On Feb 10, 2020, at 17:47, David Kastrup <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

David Kastrup
David Kastrup <[hidden email]> writes:

> Dan Eble <[hidden email]> writes:
>
>> On Feb 10, 2020, at 17:47, David Kastrup <[hidden email]> 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).

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

Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

Dan Eble
On Feb 10, 2020, at 21:35, David Kastrup <[hidden email]> wrote:
> property_set (grob, "stencil", SCM_BOOL_F);
>
> and
>
> property_get (grob, "color")

These are fine.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

Joram Berger
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

Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

Dan Eble
In reply to this post by David Kastrup
On Feb 10, 2020, at 20:48, David Kastrup <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

David Kastrup
Dan Eble <[hidden email]> writes:

> On Feb 10, 2020, at 20:48, David Kastrup <[hidden email]> 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 <const char *symbol>
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".

Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

hanwenn
In reply to this post by David Kastrup
On Mon, Feb 10, 2020 at 11:48 PM David Kastrup <[hidden email]> 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 - [hidden email] - http://www.xs4all.nl/~hanwen
Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

David Kastrup
Han-Wen Nienhuys <[hidden email]> writes:

> On Mon, Feb 10, 2020 at 11:48 PM David Kastrup <[hidden email]> 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".

Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

hanwenn
On Tue, Feb 11, 2020 at 10:17 PM David Kastrup <[hidden email]> 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 - [hidden email] - http://www.xs4all.nl/~hanwen
Reply | Threaded
Open this post in threaded view
|

Re: Naming question for get_property, set_property

David Kastrup
Han-Wen Nienhuys <[hidden email]> writes:

> On Tue, Feb 11, 2020 at 10:17 PM David Kastrup <[hidden email]> 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".