Re: Refactor get/set_property to take the item as first argument (issue 573670043 by address@hidden)

[dak]

On 2020/04/12 10:35:24, hanwenn wrote:
> On Sat, Apr 11, 2020 at 3:55 PM David Kastrup <mailto:address@hidden>
wrote:
> > >> You haven't understood the scheme.  A grob only contains the
properties
> > >> seminal to its type.  That's why there is a double indirection. 
A full
> > >> array of 416 entries is needed per grob _type_, not per grob.
> > >
> > > I still don't see why this requires an overall overhaul of the
> > > internal calling convention. You can have a global registry of
symbol
> > > => uint16 (numbering all the symbols),
> >
> > It would be pointless to have a single registry for music
properties,
> > grob properties, stream event properties, and context properties,
thus
> > significantly blowing up the second-level indexing tables and making
for
> > a large number of cache misses.
> 
> there are 400 grob properties, and about 800 properties in total
> (including music and context). 400 requires 9 bits, 800 requires 10
> bits. It doesn't appreciably change the problem size.

Populating arrays densely or sparsely makes a large difference in how
well they fit caches.  However, this is completely irrelevant since this
patch does not, I repeat _not_ enforce any particular implementation. 
All that it does is provide the macros with more complete information
and thus enables implementations that are not crippled down by having
macros pretend to be able to deal with overload resolution.

That you don't feel that you are able to make use of that change does
not mean that you are the only developer who should be allowed to work
on such problems and consequently should be able to block off any
attempt of restructuring the source code in a manner that allows other
developers to more easily experiment with other approaches without
having to constantly resolve rebase conflicts because a design decision
unsuitable for refactoring is kept in place for no good reason.

You'll find that we have had several restructurings of macro call
locations in the past years in order to facilitate refactorings, some
with more, some with less success and permanent impact.  In general, the
developers proposing them had reasonable expectations for the directions
those changes would open for them, and reasonable consideration for the
impact on others.  Please keep in mind that LilyPond, as it stands now,
is a colloborative project.  Accommodating the work of others to
proceed, given reasonable goals and impact, is therefore a necessity.  A
stance that amounts to "I cannot make that work, so we shouldn't move in
a direction where you could try" is not really useful for a
colloborative effort of developers with equal standing.

I had several other proposals of syntax that would provide required
information to the macros in case, but this is the least intrusive one
that retains some flavor of overloading.

https://codereview.appspot.com/573670043/