Reconstruction expression with explicit deconstuctor (REWED)
David Alayachew
davidalayachew at gmail.com
Thu Oct 19 01:04:27 UTC 2023
Apologies for the incorrect cross post.
I see what you mean.
The value that I saw was if Thingie from your example had an alternative
deconstructor that only outputted a and b. That way, the default is the
given deconstructor, but you can opt into using a separate deconstruction
pattern (deconstructor, static pattern, or instance pattern) instead of the
default.
On Wed, Oct 18, 2023 at 8:23 PM Brian Goetz <brian.goetz at oracle.com> wrote:
> (cross-posting to -comments is discouraged)
>
> If we are reconstructing something as trivial as a Point, we might not
> even use a reconstruction expression, since an ordinary constructor
> invocation is probably good enough (it only has two components, and we're
> changing at least one of them.)
>
> Now imagine you are reconstructing something with a dozen components,
> which is where reconstruction expressions offer more value. I don't think
> people would be very happy with a syntax like
>
> thingie with Thingie(var a, var b, var c, var d, var e,
> var f, var g, var h, var i, var j) { a = 3 }
>
>
>
> On 10/18/2023 8:01 PM, David Alayachew wrote:
>
> Also adding @amber-dev <amber-dev at openjdk.org>
>
> On Wed, Oct 18, 2023 at 8:00 PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Adding -comments
>>
>> On Sat, Sep 23, 2023 at 10:54 AM Attila Kelemen <
>> attila.kelemen85 at gmail.com> wrote:
>>
>>> Note: I think you would have a better chance, if you sent the email to
>>> "amber-spec-comments" than "observers", since the people who can actually
>>> make changes are more likely to read the "comments" list.
>>>
>>> That said, I don't really see the usefulness of such a syntax (and
>>> adding new syntax in itself is a detriment). That is, if I understood you
>>> correctly, then your example would replace this:
>>>
>>> ```
>>> Point p = ...;
>>> Point pp = new Point(p.x() + 2, 0);
>>> ```
>>>
>>> which is shorter and a lot more obvious. And if we were to go to more
>>> complicated things (many properties), then it doesn't help that much,
>>> because as far as I understand you, your proposal is still positional in
>>> its deconstruction pattern, and the positional nature is usually what is
>>> awkward in structures with many properties.
>>>
>>>
>>> Harrison Chikwe <nhcdeveloper at gmail.com> ezt írta (időpont: 2023.
>>> szept. 23., Szo, 12:01):
>>>
>>>> Hi,
>>>>
>>>> I think that it is very useful to have when working with immutable
>>>> objects.
>>>>
>>>> For the purposes of this mail, let's call the design described in the
>>>> ambro-doc[1]:
>>>> reconstruction expression with implicit deconstructor (aka REWID).
>>>>
>>>> Has it been considered to make the deconstructor pattern explicit in
>>>> the reconstruction
>>>> expression (aka REWED)?
>>>> Doing so may remove the requirement to make names more significant in
>>>> the language.
>>>>
>>>> For example, given the following:
>>>>
>>>> Point p = ...;
>>>> Point pp = p with(int x, int y) { x += 2; y = 0; }
>>>>
>>>> We can interpret the reconstruction expression above as:
>>>>
>>>> . Find a deconstructor and constructor pair that has a signature that
>>>> matches (int, int)
>>>> . Deconstruct the target with the deconstructor
>>>> . Execute the block on RHS
>>>> . Invoke the constructor with the result.
>>>>
>>>> If we split the reconstruction expression into three steps:
>>>>
>>>> 1. Extraction
>>>> 2. Transformation
>>>> 3. Construction
>>>>
>>>> In REWID users are required only to do step 2 (transformation) and the
>>>> system handles 1 and 3. Whereas in REWED users are required to do step
>>>> 1 and 2
>>>> and the system handles just step 3.
>>>>
>>>> # Other forms of REWED
>>>>
>>>> 1. Explicit Named deconstructor pattern
>>>>
>>>> Point pp = p with Point(int x, int y) {...}
>>>>
>>>> 2. Explicit Var deconstructor pattern
>>>>
>>>> Point pp = p with var(int x, int y) {...}
>>>>
>>>> 3. Explicit Unnamed deconstructor pattern
>>>>
>>>> Point pp = p with(int x, int y) {...}
>>>>
>>>>
>>>> We can extend form 1 to include factory pattern:
>>>>
>>>> Point pp = p with Point.factory(int x, int y) {...}
>>>>
>>>>
>>>> # Advantages
>>>>
>>>> 1. No need to make names significant.
>>>> 2. Can be combined with other patterns (e.g. unnamed pattern, var
>>>> pattern)
>>>>
>>>> Point pp = p with(int x, _) { x = 0; }
>>>>
>>>>
>>>> Nyehamene.
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20231018/705b5135/attachment.htm>
More information about the amber-spec-observers
mailing list