groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: New syntax explosion
Date Fri, 06 Oct 2017 04:43:27 GMT
Yes, we should probably do a bit of a review. Some of the features drifted
from experimental branches into master without heaps of discussion. From my
point of view, higher priority right now is getting 2.5 pushed along and
out the door and some JDK 9 issues progressed, then we can start looking at
2.6 in much greater depth. While we are in the alpha stage for 2.6, I am
not too concerned. But we shouldn't be complacent, we'll want our friends
in the IDE world (and various other tools) to start looking at 2.6 soon and
we don't want to send them down any dead ends.

Cheers, Paul.

On Fri, Oct 6, 2017 at 9:12 AM, Jochen Theodorou <blackdrag@gmx.org> wrote:

> On 06.10.2017 00:06, Jesper Steen Møller wrote:
>
>> Hi List
>>
>> On 5 Oct 2017, at 20.01, eric.milles@thomsonreuters.com <mailto:
>>> eric.milles@thomsonreuters.com> wrote:
>>>
>>> [...]
>>> `a??.b.c.` is just `a?.b?.c`
>>>
>>
>> Are there any cases where a?.b.c would every make sense -- if a is null,
>> then the expression would throw anyway, wouldn't it? Or is there some
>> dynamic mixin case I'm not taking into consideration?
>>
>> In other words, IMHO a?.b.c should implicitly mean a?.b?.c or at least
>> give a warning that the construct doesn't make sense. In either case ??.
>> wouldn't make much sense.
>>
>
> I personally think we made a mistake with ?. Instead of safe navigation,
> we should stop evaluation
>
> x = a?.b?.c?.d
>
> is translated as:
>
> var tmp
> tmp = a==null?null: a.b
> tmp = tmp==null?null: tmp.c
> tmp = tmp==null?null: tmp.d
> x = tmp
>
> and x = a?.b.c.d is
>
> var tmp
> tmp = a==null?null: a.b
> x = tmp.c.d
>
> while x = a??.b.c.d is
>
> var tmp
> tmp = a==null?null: a.b.c.d
> x = tmp
>
> As you can see the constructs a??.b.c.d and a?.b?.c?.d can have different
> implementations.
>
> I would favor replacing ?. with what ??. does. I doubt it would really
> break any programs.
>
> As for the other constructs, I'm also not a big fan of introducing lots of
>> new syntax just because we can.
>> There is a collateral cost to pay, e.g. in the type checker and static
>> compiler (within the Groovy project's control), too, and in every AST
>> transformer which needs to know about the new stuff (out of the
>> Groovyproject's control!) .
>>
>
> well, that is where the current version shines... They are parse time
> constructs, no new AST required, no new compilation required (only for
> optimization), no new checks required.
>
> But I would go further... just because the collateral cost is low, does
> not make the construct more appealing. For syntax, semantics and use-case
> have to decide.
>
> bye Jochen
>
>

Mime
View raw message