Rémi,
I get the impression that, in introducing the notion of a “carrier”, you seem
to be focused on how deconstructors and patterns will necessarily be
implemented in terms of the current definitions of Java and the JVM, or at
least trying to explain it to the user (Java programmer) in terms
We've had this discussion before.
In the old model, it *is* a two-step process; processors could cache
type and analysis information in the indy call site at capture time
through the Linkage mechanism, and then could use that information at
application time. It's just that in the old model,
Despite several years of warnings and other attempts at preparing the
ground, you seem intent on falling into the trap of thinking that these
things are "just methods" and that we are better served by generalizing
methods to support patterns. Everything about the model here places
patterns as
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, April 3, 2024 2:48:40 PM
> Subject: Re: Member Patterns -- the bikeshed
> I would summarize your comments below as: Let's throw the entire model in the
> garbage, and replace it with something like Scala's
I would summarize your comments below as: Let's throw the entire model
in the garbage, and replace it with something like Scala's "return an
Optional" instead.
We've been discussing the model for several years; you've been asking
(and waiting patiently) for "when are we going to talk about
Hello,
I would be even more brutal here because I think that the reason *alternative
representation* is better serve by factory methods than constructors.
The same way, in term of de-constructrion, for *alternative representation*, a
named method pattern is better than a deconstructor.
So
Hello,
I think it is also interesting to instead of starting from deconstruction and
then trying to expand, to do in the other way, starts with a pattern backed by
a method and then see the deconstruction as a special case of a pattern backend
by a method. So instead of using a top-down
