Jep 468: What about 'new' syntax?

[Ryan Leach]

Since first responding I've now done considerable brushing up on the
various amber archives, and have gained a better understanding of the
resistance to anything that looks like by-name abuse of derived record
creation.

I look forward to being able to use 'with' with other patterns, and agree,
that, given the transformation that Java will undertake in the coming years
with the various plans for pattern matching, that this will probably fit in
fine as "Java-like".

Would still prefer to have 'new', but alas, I'm just one small opinion
amongst many, and don't have anything further to add discussion wise that
Remi hasn't covered in the expert group, and would not have replied if I
hadn't managed to accidentally drop amber-dev as a cc.

On Fri, Nov 22, 2024 at 10:47 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Let's set aside the syntax; suffice it to say there are probably several
> million who like and several million who don't, for basically any option,
> so one more vote yea/nay does not move the needle.
>
> But I do want to take exception to "not powerful enough" (and also, to
> some degree, "not Java-like"); it is actually far more powerful than what
> other languages do in this space, but not in an obvious way.
>
> Most languages that have a feature like this are fairly constrained.
> Either you can only do property assignments, or there is some "DSL" subset
> of the language that you can use.  The block on the RHS, on the other hand,
> can contain any Java statement -- loops, conditionals, whatever.  It is not
> a constrained subset.
>
> You can consider a `with` block `x with { STATEMENTS }` to be largely
> equivalent to:
>
>     x = switch (x) {
>         case TypeOfX(COMPONENTS) -> { STATEMENTS; yield new
> TypeOfX(COMPONENTS); }
>     }
>
> The `with` syntax is largely sugar for this.
>
> When you can declare patterns in arbitrary classes, `with` will work with
> them as well.
>
>
>
>
>
> On 11/21/2024 1:25 AM, Ryan Leach wrote:
>
> That's fair Brian.
>
> In truth when I was writing this post, the stuff about object initializers
> was tacked on as I was thinking through potential pitfalls and potential
> benefits of alternative syntax then that proposed by the JEP.
>
> I still think my original point has strength in 'new' being used for
> readability and teachability.
>
> If it seems wordy, I agree, but I'm not in love with the 'with' keyword,
> reviewing other languages, it seems there's a vast variety of uses for the
> 'with' keyword already existing, and independently, various ways of
> tackling the copy-with-changes problem.
>
> The ambiguous use of 'with' does mean it's kinda free real estate,
> especially since some uses coincide with record / struct copying.
>
> The only benefit I can see from the current preview, where `with` can only
> be used with records (which seems a little restrictive) is the ability to
> treat them like left hand side values, and thus able to use stuff like ` =*
> 2` which seems a little niche, but I think, innovative.
>
> But it just doesn't feel "Java-like" and doesn't provide enough power to
> justify its own keyword in its current form (in my opinion).
>
> (If there's loose ideation level plans for future directions to take it,
> that's probably why.)
>
> A review of how other languages do record/struct/object copying looks like
> it's a choice of either
>
> 1. object destructuring syntax.
> 2. 'with'-like copying (even if it uses other symbols or keywords)
> 3. Copy methods with by-name optional parameters.
>
> So I'm kinda at a loss on whether this is even the best way to approach
> this solution now after looking into it more.
>
> ---
>
> Where can I find reading on how this feature was developed? I feel like
> I'm probably retreading old ground, perhaps needlessly.
>
> ---
>
> As a brief aside for context, I've had professional work as a C#
> programmer in the past, and I've experienced friction to the amount of
> 'needless' language additions they've made vs languages like Scala,
> especially in regards to stuff like all the different property syntax that
> exists, because of the amount of "fiddling" required as a class evolves as
> the syntax doesn't always lead itself well to being edited between one form
> and another.
>
> For this reason, I'm a little against changes that don't feel orthogonal
> or language-native being bolted on to fix specific problems.
>
> On Thu, 21 Nov 2024, 3:23 am Brian Goetz, <brian.goetz at oracle.com> wrote:
>
>> While I would not say that the `x with B` syntax is written in stone, I
>> don't think just stapling `new` to it is helpful.  I will point out (as I
>> have several times before) that I think trying to coerce the `with` syntax
>> into a way to get by-name invocation of constructors is a very bad move.  I
>> totally get why people keep reaching for it, but it's the wrong way to get
>> there.  Maybe we'll get there some other way, maybe we won't, but we
>> definitely won't get there this way.
>>
>>
>> On 11/20/2024 11:46 AM, Olexandr Rotan wrote:
>>
>> Yea, Brian, I agree with you. I wasn't even proposing that as argument
>> against proposal, more like a nasty little detail, hence this is a "side
>> note". Moreover, if (or, I hope, when) more record features expanded to all
>> classes, compiler will still be required to clone non-value objects since
>> they can be mutable, and with implies making a copy (although not always
>> actually has to do it as in my example).
>>
>> But I gave more thought to this today, and what I have concluded is that
>> I would rather vote against it. The reason is that only value that "new"
>> brings to the table here is better "human readability". But, for me it
>> seems more like a mumbling. I am, I guess, more of a writablity guy than
>> most people here, so I don't really like mumbling. Also it is some noise
>> for reader. "New" here does not help resolve some ambiguity nor for
>> compiler nor for reader, at least as it seems for me. That's why I would
>> say I am not a fan of this syntax
>>
>> On Wed, Nov 20, 2024, 15:18 Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>>>
>>> > Hello. Just a side note: AFAIK "new", by spec, guarantees that new
>>> > instance of object is returned
>>> >
>>>
>>> Historically this is true.  However, when Valhalla gives us value types,
>>> the "new"-ness of a new value object will be indistinguishable from an
>>> old object.  So I would advise against taking this "new means new"
>>> dictum too literally.
>>>
>>> > , so it can potentially affect implementation requirements for
>>> > compilers, forcing them to copy records even if with expression block
>>> > is empty, i.e.
>>> >
>>> > var b = new a with {}
>>> >
>>> > Unless there is a exception for such syntax, new will mandate that b
>>> > != a (by reference)
>>> >
>>>
>>> ... unless a and b are value objects, in which case == compares their
>>> state, not their identity (because they have none.)
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241122/630b0e0f/attachment.htm>