enum constant to
get its class but that enum constant may not be initialized at the time the
type is needed.
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "Kevin Bourrillion"
> Cc: "amber-spec-experts"
> Envoyé: Mardi 18 Décembre 2018 18:27:13
&
In this feature, there are two changes (that we know of so far) that
might cause such observable effects.
1. Not erasing the type parameter of Enum when computing the super
type of a raw enum type.
2. Changing the translation of enum constants. Right now, if you
have an enum constant t
Sorrt for the very late reply - yesterday I was writing this, but got
hijacked by Xmas party :-)
On 12/12/2018 16:40, Kevin Bourrillion wrote:
What proportion of enum use cases benefit from this? Offhand, I would
have to guess that it is less than 0.1% (and if it turned out to be
/far/ less i
llion"
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 12 Décembre 2018 18:01:06
> Objet: Re: enhanced enums - back from the dead?
> Yes, you could spin this feature as “its sort of for experts”, note the
> incremental complexity, and then raise the “why bother” flag. That’s
> Secondly, it's hard to imagine there being any unforeseen consequences of
> switching on a long. Here, I don't really know how to think it through yet. I
> would appreciate any "here's how we know that the changes we need to support
> this will have no user-visible consequences at all except
> Thanks to your explanation I see that this case is like that one in theory.
> It's not quite the same thing in practice. That is, I know that a person can
> both read and write "switch (someLong)" with no puzzlement, but I don't think
> the same is true here; enumness and genericness are conc
Yes, you could spin this feature as “its sort of for experts”, note the
incremental complexity, and then raise the “why bother” flag. That’s a valid
question.
But, I prefer to look at this feature in a different way. This is not, IMO,
just “let’s make enums do more.” This is about _simplif
On Tue, Dec 11, 2018 at 12:25 PM Brian Goetz wrote:
This uber-conservative approach seems a pretty reasonable approach to
> me; after all, enums are a language feature, and Enum is a
> constrained class (can't implement it directly), so it is not
> unreasonable to define its typing wrt its supert
This uber-conservative approach seems a pretty reasonable approach to
me; after all, enums are a language feature, and Enum is a
constrained class (can't implement it directly), so it is not
unreasonable to define its typing wrt its supertypes specially.
So, let's get back to Maurizio's origin
On 11/12/2018 14:02, Brian Goetz wrote:
Received on the -comments list.
Forwarded Message
Subject:Re: enhanced enums - back from the dead?
Date: Tue, 11 Dec 2018 11:13:52 +
From: elias vasylenko
To: amber-spec-comme...@openjdk.java.net
So going back a
Received on the -comments list.
Forwarded Message
Subject:Re: enhanced enums - back from the dead?
Date: Tue, 11 Dec 2018 11:13:52 +
From: elias vasylenko
To: amber-spec-comme...@openjdk.java.net
So going back a little, the suggestion of Rémi is to have
On 10/12/2018 23:58, Brian Goetz wrote:
If we restrict this only to enums, of course this would be a non-issue; as you
say, enums are non-generic right now, so we have a clean slate (assuming we're
ok with the asymmetry).
There’s an even more conservative option: restrict this only to the
> If we restrict this only to enums, of course this would be a non-issue; as
> you say, enums are non-generic right now, so we have a clean slate (assuming
> we're ok with the asymmetry).
>
There’s an even more conservative option: restrict this only to the type
variable of Enum>, not just
Thanks for the data - I guess the takeaway is that, as expected, making
type-checking of raw typing sharper will help migration (e.g. add type
parameters to existing code that might use some generic signatures
already), but it comes at the cost of some source incompatibility.
If we restrict t
Thanks for the data!
Can you clarify: is 1 out of 55Kfiles for the "all raw type refs"
option, or the "only for raw enum refs"? It looks like you are saying
the former?
On 12/10/2018 4:27 PM, Liam Miller-Cushon wrote:
I did some corpus analysis for the following question from your doc:
I did some corpus analysis for the following question from your doc:
There is a question on how broadly we want to affect typing rules for raw
> types; one option is to alter the rules for all type references; another,
> more conservative option, would be to use the refined rules only for enum
> r
On 08/12/2018 12:45, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Maurizio Cimadamore"
À: "Remi Forax"
Cc: "amber-spec-experts"
Envoyé: Samedi 8 Décembre 2018 00:57:58
Objet: Re: enhanced enums - back from the dead?
[...]
It's not that i do
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Remi Forax"
> Cc: "amber-spec-experts"
> Envoyé: Samedi 8 Décembre 2018 00:57:58
> Objet: Re: enhanced enums - back from the dead?
[...]
>>
>> It's not that i don't l
t.of(args));
}
}
regards,
Rémi
- Mail original -----
De: "Maurizio Cimadamore"
À: "amber-spec-experts"
Envoyé: Mercredi 5 Décembre 2018 17:14:59
Objet: enhanced enums - back from the dead?
Hi,
as mentioned in [1], the work on enhanced enum stopped while ago as we
have foun
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Remi Forax"
> Cc: "amber-spec-experts"
> Envoyé: Jeudi 6 Décembre 2018 20:23:05
> Objet: Re: enhanced enums - back from the dead?
> On 06/12/2018 16:53, fo...@univ-mlv.fr wrote:
&
On 06/12/2018 16:53, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Maurizio Cimadamore"
À: "Remi Forax"
Cc: "amber-spec-experts"
Envoyé: Jeudi 6 Décembre 2018 09:54:09
Objet: Re: enhanced enums - back from the dead?
Hi Remi, some comments inline.
O
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Remi Forax"
> Cc: "amber-spec-experts"
> Envoyé: Jeudi 6 Décembre 2018 09:54:09
> Objet: Re: enhanced enums - back from the dead?
> Hi Remi, some comments inline.
>
> On 05
h("-all", it -> bean.all = true)
.parse(List.of(args));
}
}
regards,
Rémi
- Mail original -----
De: "Maurizio Cimadamore"
À: "amber-spec-experts"
Envoyé: Mercredi 5 Décembre 2018 17:14:59
Objet: enhanced enums - back from the dead?
Hi,
as mentioned i
new LineParsing()
.with("-input", it -> bean.input = Path.of(it.next()))
.with("-all", it -> bean.all = true)
.parse(List.of(args));
}
}
regards,
Rémi
- Mail original -
> De: "Maurizio Cimadamore"
> À: "
Yes, the compiler special cases raw types warnings for j.l.Class type
arguments and also when doing instanceof. That is, in this program:
import java.util.List;
class Test {
void test(List ls) {
ls = (List)null;
boolean b = (ls instanceof List);
Class cl = List.class;
}
}
On Wed, Dec 5, 2018 at 8:19 AM Maurizio Cimadamore <
maurizio.cimadam...@oracle.com> wrote:
* Our proposed treatment for generic enums raises an additional, more
> philosophical, question: what are raw types *for* and how happy are we
> in seeing more of them (in the form of raw enum types)?
>
I
Hi,
as mentioned in [1], the work on enhanced enum stopped while ago as we
have found some interoperability issues between generic enums and
standard enum APIs such as EnumSet/EnumMap.
Recently, we have discussed a possible approach that might get us out of
the woods, which is described in gr
27 matches
Mail list logo
