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

[David Kastrup]

David Kastrup <address@hidden> writes:

> Han-Wen Nienhuys <address@hidden> writes:
>
>> On Tue, Feb 11, 2020 at 10:17 PM David Kastrup <address@hidden> 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.

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