@Brian: I agree that with the proposed change, the users will have to treat pattern variables "a little different" - but consider the following code:
private String x;
public void f(Object obj, boolean b) {
// first x refers to field x, 2nd and 3rd x refer to pattern variable
if ((x
Since locals can shadow fields, not allowing pattern variables to shadow
fields would likely seem to users as a strange kind of irregularity, and
they surely won't understand why they have to make up a new name. (And
worse, when they find out, they won't like the answer: because someone
else m
Hi Manoj,
by "field" you mean only fields or everything in the scope with the same name,
like capturable local variable with the same name.
Rémi
> De: "Manoj Palat"
> À: "Remi Forax"
> Cc: "amber-spec-experts" , "Brian Goetz"
>
> Envoyé: Mercredi 6 Mai 2020 18:06:20
> Objet: RE: Swiss Chee
Hi Brian,
Our proposal was "disallowing a pattern variable to shadow a field." - I don't see that this approach was tried from your mail.
Was this tried - Is there any problem which you see with this approach?
Regards,
Manoj
- Original message -From: Remi Forax Sent by: "amber-spec-exp
> De: "Remi Forax"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 6 Mai 2020 17:08:33
> Objet: Re: Swiss Cheese Issue - Revisit?
>> De: "Brian Goetz"
>> À: "Remi Forax"
>> Cc: "Manoj Palat" , "amber-spec-experts"
>>
>> Envoyé: Mercredi 6 Mai 2020 16:41:33
>> Objet: Re: Swis
We have made some presentational changes to the spec for JEP360 (Sealed Types),
which are available at:
http://cr.openjdk.java.net/~gbierman/jep360/latest/
The only semantic change is a new error if the direct superclass or direct
superinterface of a local class is `sealed`. A more comp
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Manoj Palat" , "amber-spec-experts"
>
> Envoyé: Mercredi 6 Mai 2020 16:41:33
> Objet: Re: Swiss Cheese Issue - Revisit?
> I think I get what you are saying, but we didn't go out of our way to
> _support_
> it, we chose _not_ to go out of our way to
I think I get what you are saying, but we didn't go out of our way to
_support_ it, we chose _not_ to go out of our way to _disallow_ it. So
it's not like we added a feature, as much as didn't disable an interaction.
Could you clarify what you mean?
On 5/6/2020 10:21 AM, Remi Forax wrote:
I w
I would like to add that the Swiss Cheese problem is specific to instanceof,
it's not a pattern matching issue per se.
So there is another far easier solution to the Swiss Cheese problem, don't
support it because instanceof will be less prominent in the future and
instanceof in equals() can be
We experimented with a "cheese shield" approach:
- compute the scope(s) of a binding variable as a set of position
ranges: s0..e0, s1..e1, ...
- compute the maximal scope for each variable: min(s0, s1, ...) ..
max(e0, e1, ...)
- treat the gaps as implicitly shadowing fields of the same name
Hi Brian, Gavin, all,
Referring to Tagir’s example in [1]
if (obj instanceof String str) {
System.out.println(str.toLowerCase()); // str refers to
pattern binding
} else {
System.out.println(str.toLowerCase()); // str refers to the field
}
which is me
11 matches
Mail list logo
