> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> Envoyé: Mardi 7 Avril 2020 20:29:52
> Objet: Re: Deconstruction but no destructuring when declaring local variables
> I'd like to take this up later, but let me read into the record a few points
> we've already discussed on this matter:
> - Yes, it is very tempting to like this syntax because in the degenerate case,
> where `Foo f` is a type pattern, it looks just like a declaration with an
> initializer, so much so that we can say "aha, you never knew Java had patterns
> from day 1!". But, ultimately this runs out of gas when patterns get more
> complicated, so be wary of being seduced by how natural it looks in the
> simplest case.
> Even the middle ground:
> Point(var x, var y) = p
> doesn't look much like a declaration,
I don't know, it's maybe familiarity. It's weird the first time you see it, but
it''s close the kind of deconstructing you have in JavaScript or C#
> or worse
> Foo() = f
> looks like, well, who knows.
x instanceof Foo() looks as weird for me.
We should not allow deconstruction pattern that doesn't introduce at least a
variable, in instanceof and in this case.
> - This really only works when the pattern is _total_ on the target type, so
> that
> the pattern provably applies (modulo null.) That can work for record
> deconstruction patterns but not always for other pattern types. Alternately,
> we
> can have a statement form "bind P = target else { ... }" for partial patterns,
> but then we lose the nice connection noted above with declarations.
Yes, for both local variable declarations and instanceof, the pattern has to be
total, that a major difference with switch.
I don't think it's wise to allow by example constants with an instanceof
x instanceof Point(var x, 11)
at the same time, if you allow local variables in patterns, you have a nice way
to write equals
class A {
int foo;
int bar;
public boolean equals(Object o) {
return o instanceof A(this.foo, this.bar);
}
}
which can be simplified to
public boolean equals(Object o) {
return o instanceof A(foo, bar);
}
but it's a step roo far IMO.
Rémi
> On 4/7/2020 2:20 PM, Remi Forax wrote:
>> There was discussions about the danger of only providing instanceof + the
>> deconstruction pattern and not a way to have the same kind of destructuring
>> when declaring local variables
>> By example, instead of
>> Point p = ...
>> int x = p.x();
>> int y = p.y();
>> one can write
>> Point p = ...
>> if (!(p instanceof Point(int x, int y)));
>> I think we should restart those discussions because variables declarations is
>> like a third places where patterns can appear (instanceof and switch being
>> the
>> other two).
>> I don't really want to propose a syntax, so the next examples will be to
>> give an
>> idea of the semantics
>> The idea is to allow patterns on the left side of an '='.
>> So
>> pattern = value;
>> We already have
>> Point p2 = p; // the type pattern
>> so if we expand it with the new patterns proposed for instanceof, we get
>> Point(int x, int y) = p; // the deconstruction pattern with explicit type
>> and
>> Point(var x, var y) = p; // the deconstruction pattern with var
>> regards,
>> Rémi
