Re: Resolving standoffs

[Carl Sorensen]

On 4/13/20, 4:38 PM, "David Kastrup" <address@hidden> wrote:

    Carl Sorensen <address@hidden> writes:
    
    > On 4/13/20, 6:17 AM, "lilypond-devel on behalf of David Kastrup"
    > <lilypond-devel-bounces+c_sorensen=address@hidden on behalf of
    > address@hidden> wrote:
    >
    > It looks to me like we have only two people who have weighed in on the 
patch:  the author (David K.) and one reviewer (Han-Wen).  Since we have only 
two votes (1 for, 1 against), there is no resolution.
    >
    > I have been holding off comments, waiting to see where things go.  I'd
    > now like to make my opinions known.
    
    Let me correct some things here.  You may decide whether that makes a
    difference to your thoughts.
    
    > 1) David has an excellent track record of making challenging things 
easier to do by thinking carefully about the implications of potentially 
arbitrary syntax.  For example, the parser has been made more robust, and the 
scheme interaction with the LilyPond parser has become much easier.  Because 
David has such an excellent track record in this regard, I am inclined to favor 
allowing this patch.
    >
    > 2) Han-Wen believes that this syntax change is potentially bad for at 
least the following reasons:
    >    a) The approach "seems laborious"
    >    b)  The approach will make it hard to add new grob-properties at 
runtime (David K. disagrees with this item -- in fact he believes it will force 
us to provide a proper interface for registering user-added properties).
    >    c)  Uses more memory -- lots of bytes per Grob.  David K. says it only 
uses ~500 bytes per Grob type, not per Grob.
    >    d) Interferes with Guile 2 adoption.  David K. says the current
    > patch has no effect on Scheme; further work on Scheme is in the
    > future.
    
    All of those points are _not_ relevant for this patch.  They are
    relevant for future work I intend to do that would be enabled by this
    patch.  This patch, however, makes no assumptions whatsoever what kind
    of followup code may be based on it.  It merely converts the use syntax
    of the get_property and related macros from member call to explicit
    call.  The details of any implementation using this are not topic of
    this patch.

Your answer here is what I had thought, but I had not seen this explicitly 
stated in your previous answers.

Since the proposed patch:

a) Does not change any current user-visible behavior
b) Affects only C++ code
c) I believed by David to be useful in the future
d) Contains all of the hard work (both automatic and manual) to update the code 
base, so no other changes are necessary

I am in favor of adopting the patch.

Thanks,

Carl