> De: "Brian Goetz" <[email protected]>
> À: "Remi Forax" <[email protected]>
> Cc: "amber-spec-experts" <[email protected]>
> Envoyé: Jeudi 13 Août 2020 15:42:40
> Objet: Re: A peek at the roadmap for pattern matching and more
>> We want a destructor, a destructor is a method that returns a list of values
>> the
>> same way a constructor takes a list of parameters.
>> The way to represent that list of value is to use a record.
> Yes, already been down that road, I did an entire sketch of this feature where
> we expose “anonymous records.” It felt really cool — for about five minutes.
> The conclusion of this exercise was that in this case, records are better as a
> _translation mechanism_ than a surface syntax.
first why ? and second, my experience is the opposite, the more there is a
difference between Java the language and the translation strategy the more it
will bite you with corner cases.
> So yes, the way to represent it is a record, but in the class file, not the
> language.
>> So we can already write a de-constructor with the current version of Java,
> As you figured out, if you cast a deconstructor as a method with a special
> name,
> you say goodbye to deconstructor overloading. And if you do make it magically
> overloadable, then it's magic,
It's not magic, it's a translation strategy like the same way with bridges, you
can have methods with the same name and different return types.
> and you’ve lost all the benefit off pretending its a method. You just moved
> the
> complexity around. And again here comes that glass half empty feeling: “Why
> can
> I only do it with this method?”. Much better to recognize that deconstruction
> is a fundamental operation on objects, just like construction — because it is.
But constructors are plain methods with some special bells and whistles (funny
names, funny rules for the initialization of this and final fields, etc).
Having a deconstructor being a method with several overloads doesn't strike me
as very magic compared to a constructor.
And you can not have several overloaded methods with different return types
because Java like C doesn't force you to specify the return type of a method
call. So unlike with a pattern where you provide the type, you don't provide
the return type when you do a method call.
>> i should wuth by example a method minMax that returns both the minimum and
>> the
>> maximum of an array
>> public static (int min, int max) minMax(int[] array) {
> Nope. Not going there. I went down this road too, but multiple-return is
> another
> one of those “tease” features that looks cool but very quickly looks like
> glass
> 80% empty. More fake tuples for which the user will not thank us. And, to the
> extent we pick _this particular_ tuple syntax, the reaction is “well then WTF
> did you do records for?”
Records are the underlying type used by the tuple syntax.
The tuple syntax is as its name suggest, just a syntax. From the semantics POV,
it's an anonymous record, thus, not a structural type.
You may use a record instead of an anonymous record, if you want to reuse the
same record for multiple deconstructor, if i have several classes representing
rectangular shape, i may want them to share the same record.
It's really very similar to the difference between a method reference and a
lambda or a classical class and an anonymous class. A record is explicitly
named, it can have annotations, it can be serializable, implements interfaces,
have it's own toString() etc. An anonymous record is the anonymous version of a
record, where you don't care about the name or resource sharing (on record per
deconstructor).
> Having records _and_ structural tuples would be silly. We’ve made our choice:
> Java’s tuples are nominal.
But the syntax you are proposing for deconstruction is using the syntax of a
_structural tuples_ . Here the glass is half empty, because why the
deconstructor can have that feature and not any methods given that at the end a
de-constructor is desugared as a method that return a record. As i said in my
original mail. I agree with you that we don't want a _structural tuples_, but
it's not, it's an anonymous record and restricted them only to deconstructor
does not make make a lot of sens.
I's like saying look this shinny anonymous record, deconstructor can use them
but not regular methods.
> Worse, it only addresses the simplest of patterns — deconstructors — because
> they are inherently total. When you get to conditional patterns
> (Optional.of(var x)), you want to wrap that record in something like an
> optional. If the return value is fake, now you have to deal with the
> interaction of trade tuples and generics. No thank you.
I don't see the issue here, where is the problem with the following code ?
Optional<(int x, int y)> deconstructor() {
return Optional.of( (this.x, this.y) );
}
Maybe users will find the syntax weird ? But it's like any new feature ?
I believe you are thinking that the type (int x, int y) is a tuple while
technically it's an anonymous record, so from the type system POV it acts as a
record, i.e. a nominal class.
> Believe me, I’ve been down ALL of these roads.
>> the compiler will generate a synthetic record, so the generated code is
>> equivalent to
> The synthetic record part is the part I liked, and kept.
> There’s room for an “anonymous tuple” feature someday, maybe, but we don’t
> need
> it now.
I'm not suggesting to introduce an anonymous tuple, as you said above, we have
decided to use record instead, a nominal type.
I'm suggesting to introduce the concept of anonymous record, which is what the
synthetic record is, because i see no point to restrict it only to
deconstructors.
> I’m willing to consider the “record conversion” when we get to collection
> literals, but not now.
To represent the couple key/value i suppose.
I don't disagree, but i don't think it's wise to introduce the idea of a
synthetic record without the notion of anonymous record, but we don't need a
synthetic record for deconstructors, it's nice to have but not an essential
part of the design.
Rémi
