Re: Resolving standoffs (was: Naming question for get_property, set_property)

[Han-Wen Nienhuys]

A couple of counter points:

100% of the reviewers of the change you proposed disagreed with it.
You call that a veto, but I don't think you can call that consensus
either. Maybe you mean that you got to push changes in the past
because nobody else could understand what they did?

I have tried to discuss your overall plans, which this change is part
of, but you have refused to listen to me, alleging we can only have a
discussion of code that is actually written ("discuss until the cows
go home .. ")

If we want to discuss only the code that is actually written, then
we're discussing this giant patch, which just moves around code. This
is not a cosmetic change, or at least not one that improves cosmetics.
You have rightfully pointed to future inferences a compiler could
make, but again, that is code that is not written yet, so under your
stance, we shouldn't be considering it.

You say you need to submit this change, because it otherwise will go
stale. I don't buy that argument. You only need this change if your
follow-on change works, ie. improves performance.  You can build your
follow-on change by just not following master; the current tip of
master is as good as any to test performance changes with. Once you
can demonstrate a tangible benefit of a follow-on change, we can
rebase/update the change currently under discussion, and I'm happy to
provide help when that time comes.

Finally you claim that my incompetence ("[Han-Wen] would not
be able") is a factor in this discussion. I obviously disagree with
this assessment. I'll let https://codereview.appspot.com/575990043/
speak for itself.

On Mon, Apr 13, 2020 at 2:17 PM David Kastrup <address@hidden> wrote:
> Well, it turns out that Han-Wen decided to veto this approach and
> unilaterally changed the status of the respective patch from "Push" to
> "Waiting".  Now the problem with this kind of extensive restructuring
> patch is that it becomes stale rather fast which is the reason why it is
> not feasible to maintain them in parallel with ongoing development.
>
> Han-Wen did not propose an alternate syntax in that discussion.  His
> argument is that he wants the macro call to look more like a method
> call, but a macro does not have the same information that the compiler
> has, and this precludes experimentation with type-dependent
> implementations of the part done by the macro.
>
> That is not a problem according Han-Wen because he thinks he would not
> be able to derive substantial benefits from that if he pursued that
> approach.
>
> That is kind of an uncommon objection and situation compared to the
> previous decade of consensus-based development, so we have two questions
> of which we need to answer at least one here:
>
> a) what kind of syntax that would be acceptable to Han-Wen as well as
> others and would allow developers to work with type-aware macro code for
> the purpose of inlined property access would be feasible otherwise
>
> b) in case where a consensus cannot be achieved after a reasonable
> discussion, how do we arrive at a decision, possibly based on the
> consequences.
>
> In this case, we are talking about a large-scale cosmetic change in a
> macro syntax call that opens up strictly more possibilities without
> enforcing any particular implementation.  That may make a difference for
> finding a solution for this particular standoff, but the kind of
> conflict and argument here suggests that there may also come future
> occasions where we will have to decide how to deal with non-consensus
> decisions in situations that are governed by significantly different
> tradeoffs.
>
> The relevant discussion partly is in the mailing list thread I now
> followed up to and that started a few months ago, and in the Rietveld
> issue at
>
> <https://codereview.appspot.com/573670043>
>
> The patch status changes and their justifications are at
>
> <https://sourceforge.net/p/testlilyissues/issues/5882/>
>
> --
> David Kastrup



-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen