From brian.goetz at oracle.com  Wed Jun 14 14:57:44 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 14 Jun 2017 10:57:44 -0400
Subject: Pattern matching -- translation
Message-ID: <808e95d0-c964-afcf-dd15-b89384283f30@oracle.com>

I've posted a writeup on a strategy for pattern match translation here:
http://cr.openjdk.java.net/~briangoetz/amber/pattern-match-translation.html

Comments welcome!

From brian.goetz at oracle.com  Wed Jun 14 15:32:53 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 14 Jun 2017 11:32:53 -0400
Subject: Pattern matching -- translation
In-Reply-To: <55A927AD-318F-47EE-83AA-4A69649DCC21@d-d.me>
References: <808e95d0-c964-afcf-dd15-b89384283f30@oracle.com>
 <55A927AD-318F-47EE-83AA-4A69649DCC21@d-d.me>
Message-ID: <ee86f808-6a81-3904-8788-bdba1d04df2e@oracle.com>



On 6/14/2017 11:21 AM, Dmitry Petrashko wrote:
>
> Hello Brian,
>
> It would be very nice to see if the technology you are developing can 
> simplify pattern matching in Scala and\or help us
> expose out pattern matching capabilities to other JVM languages.
>
Absolutely.

Bridging an existing unapply method to a __Pattern should be trivial, 
meaning that existing Scala classfiles, without recompilation, still 
have a path to playing.  For newly compiled classfiles, you further have 
the option of generating __Pattern factories as well.  So there should 
be a clean story for both old code and new.

> Scala has an additional specced requirement to the patterns: 
> |unapply|-s should be pure, not mutate any environment of the objects 
> that they are given. This means that we can potentially remove calls 
> to them if we know that they won?t match and not worry about removing 
> side-effects. It would be nice to know our opinion of if you?d like to 
> have a similar limitation on your |predicate|s.
>

While we can't enforce this, we can tell people that they get no 
guarantees about the ordering or execution arity of side effects. So, 
yes, basically the same deal, just in different language.

> On a minor note your Scala examples are slightly outdated. We 
> currently have a scheme that commonly does not allocate any new objects:
>

Can you post a more detailed translation scheme for the non-case-class case?

> The most important part is that case classes in Scala automatically 
> synthesise those methods on the class instance.
> This allows for |unapply| to be an identity method, that does not 
> require any allocations! No options or topples get allocated.
>

This sounds like it has a similar effect to the optimization where we 
use an object as its own carrier, at least for case classes?


From maurizio.cimadamore at oracle.com  Thu Jun 15 11:58:37 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 15 Jun 2017 12:58:37 +0100
Subject: [enhanced enums] - end of the road?
In-Reply-To: <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
 <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
Message-ID: <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>

I think the moral equivalent of what you wanted to say is something like 
this:

enum Option implements Consumer<String> {
    D implements Generic<String>("-d", ...) { ... }
    PROC implements Generic<ProcOption>("-proc", ...) { ... }

    ...

}

Which is not too terrible (in fact has been put forward by John as a 
comment in the JEP [1]).

That said, if we went down that path, note that, at least in my 
re-formulation, there's no way to view Option as a subtype of Generic. 
In other words, the enum as a whole would have nothing to do with 
Generic, subtyping wise. Now, I think for the particular use case we 
were considering, this could be still ok - at the end of the day we 
wanted to write something like:

public Z get(Option<Z> option) { ... }

and in this model we could rewrite this as:

public Z get(Generic<Z> option) { ... }

One observation, if we had sealed interface, one could do this:

enum Option implements Consumer<String> {

     ...

     sealed interface Generic<X> { ... }
}

so that the interface can only be effectively implemented by the enum 
constants.


So, what you're saying (or what I'm inferring from what you're saying 
:-)) is: if we can't have generic on enums, having custom generic 
supertypes on constants seems a pretty good approximation. Which is, I 
think, a fair point.

[1] - 
https://bugs.openjdk.java.net/browse/JDK-8170351?focusedCommentId=14064981&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14064981


On 15/06/17 12:43, Peter Levart wrote:
> Hi Maurizio,
>
> What if the enum type was kept non-generic, but there could optionally 
> be a designated generic supertype inserted between the enum type and 
> the constant type. For example:
>
> public enum Option implements Consumer<String> super Generic  {
>     D<String>("-d", ...),
>     PROC<ProcOption>("-proc", ...),
>     ...;
>
>     class Generic<T> implements Function<String, T> {
>         Generic(...) {
>             super(...);
>         }
>
>         public T apply(String s) {
>             ...
>         }
>     }
>
>     Option(...) {
>         ...
>     }
>
>     public void accept(String s) {
>         ...
>     }
> }
>
>
> this would translate to:
>
> public class Option extends Enum<Option> implements Consumer<String> {
>
>     public static final Generic<String> D = new Generic<>("D", 0, 
> "-d", ...);
>     public static final Generic<ProcOption> PROC = new 
> Generic<>("PROC", 1, "-proc", ...);
>     ...
>
>     static class Generic<T> extends Option implements Function<String, 
> T> {
>         Generic(String name, int ordinal, ...) {
>              super(name, ordinal, ...);
>         }
>
>         public T apply(String s) {
>             ...
>         }
>     }
>
>     Option(String name, int ordinal, ...) {
>         super(name, ordinal);
>         ...
>     }
>
>     public void accept(String s) {
>         ...
>     }
> }
>
>
> The "super" keyword in enum declaration could only designate a class 
> in the same compilation unit - the enum member static class.
>
> Hm...
>
>
> Regards, Peter
>
> On 05/23/2017 07:49 PM, Maurizio Cimadamore wrote:
>> Hi,
>> over the last few weeks we've been carrying out experiments to test 
>> the feasibility of the enhanced enums feature. As described in the 
>> JEP, this feature is particularly powerful as it allows enums 
>> constants to be carrier of generic type information, which can then 
>> be fed back to the inference machinery.
>>
>> One experiment we wanted to make was to see if enhanced enums could 
>> make javac's own Option [1] enum better. This enum defines a bunch of 
>> constants, one for each supported javac command line arguments (e.g 
>> -classpath, -d, etc.). Furthermore, the enum defines method so that 
>> each constant can be parsed given the javac command line and 
>> processed, accordingly to some OptionHelper. Most options, along with 
>> the value of their arguments would simply be stored into a 
>> Map<String, String>, which is the backbone of the Options class [2].
>>
>> One problem with storing option values as Strings is that clients 
>> need to do the parsing. So, if an option has an integer argument, 
>> it's up to the client to get the value of that option off the map, 
>> parse it into a number and (maybe) check as to whether the range 
>> makes sense.
>>
>> With enhanced enums it should be possible to do better than this; 
>> more specifically, if enums supported generics, each option could 
>> specify a type argument - that is, the type of the argument that 
>> javac expects for that particular option.
>>
>> So, an option with a plain String argument would be encoded as 
>> Option<String>, as follows:
>>
>> D<String>("-d", ...)
>>
>> While an option for which multiple choices are available, could be 
>> encoded using an enum as a type-argument - for instance:
>>
>> PROC<ProcOption>("-proc", ...)
>>
>> where ProcOption would be defined as follows:
>>
>> enum ProcOption {
>>    NONE, ONLY;
>> }
>>
>> Finally, for an option whose argument can be a set of values, we 
>> would use the following encoding:
>>
>> G_CUSTOM<EnumSet<DebugOption>>("-g:",  ...)
>>
>> where DebugOption would be defined as follows:
>>
>> enum DebugOption {
>>     LINES, VARS, SOURCE;
>> }
>>
>> So, instead of storing all options into a Map<String, String>, we 
>> could store them into a Map<Option, Object>. Then, we would turn the 
>> Options.get method from this:
>>
>> public String get(String option) { ... }
>>
>> to something like this:
>>
>> public Z get(Option<Z> option) { ... }
>>
>> granted, there will be some unchecked operations carried out by the 
>> body of this method, but the map should be well-constructed by 
>> design, so it should be safe. What we get back is that now clients 
>> can do things like:
>>
>> boolean g_vars = options.get(Option.G_CUSTOM).contains(DebugOption.VARS);
>>
>> Note how we raised the expressiveness level of the client, which no 
>> longer has to do parsing duties (and domain conversions). So, that 
>> was the experiment we wanted to carry out - ultimately, this is the 
>> kind of stuff you'd like to be writing with enhanced enums, so this 
>> seemed like a reasonably comprehensive test for the feature.
>>
>>
>> Unfortunately, the results of the experiment were not as successful 
>> as we'd hoped. As soon as we turned the Option enum into a generic 
>> class (by merely adding a type parameter in its declaration), we 
>> immediately started hitting dozens of compile-time errors. The errors 
>> were rather cryptic, all pointing to some obscure failure when 
>> calling EnumSet.noneOf or EnumSet.allOf with the newly generified 
>> Option class. In other words, code like this:
>>
>> EnumSet.noneOf(Option.class)
>>
>> Was now failing. The issue that was underpinning all these failures 
>> is - in retrospect - rather obvious: the following type:
>>
>> EnumSet<Option>
>>
>> is *not* a well-formed type if Option is a generic class. Why? Well, 
>> EnumSet is declared like this:
>>
>> class EnumSet<*E extends Enum<E>*> { ... }
>>
>> which means the type parameter has an f-bound. In concrete terms, we 
>> have to check that:
>>
>> Option <: [E:=Option]Enum<E>
>>
>> That is, the actual type-argument must conform to its declared bound. 
>> But if we follow that check, we obtain:
>>
>> Option <: [E:=Option]Enum<E>
>> Option <: Enum<Option>
>> Enum (*) <: Enum<Option>
>> false
>>
>> (*) note that Option is now a 'raw' type - and a raw type has all 
>> supertypes erased, as per JLS 4.8.
>>
>> In other words, there's no way to write down the type of an enum set 
>> which contains heterogeneous options - the wildcard path doesn't help 
>> either:
>>
>> EnumSet<Option<?>>
>>
>> As, the above check would develop in the following way:
>>
>> Option<?> <: [E:=Option<?>]Enum<E>
>> Option<?> <: Enum<Option<?>>
>> Enum<#CAP> (**) <: Enum<Option<?>>
>> false
>>
>> (**) the supertype of a wildcard-parameterized type is obtained by 
>> first capturing, and then recursing to the supertype, as per JLS 4.10.2
>>
>>
>> In other words, generic enums are not interoperable with common data 
>> structures such as enum sets (and, more generally, with any f-bounded 
>> generic data structure).
>>
>> While we could just deliver the part of JEP 301 regarding sharper 
>> typing of enum constants and leave generic enums alone, we feel 
>> there's not much value into pursuing that path alone. After all, the 
>> benefits of enhanced enums were exactly in combining sharper typing 
>> with generic type information, so that enum constants could be used 
>> as type carriers. If generic enums are not viable, then much of the 
>> usefulness of this JEP is lost.
>>
>> It is unclear at this point in time if type system improvements 
>> (which we are pursuing as part of a separate activity [Dan is there a 
>> link for this??]) would ameliorate the situation.
>>
>> Until we figure this out, I suggest that we put this JEP on hold for 
>> the time being
>>
>> [1] - 
>> http://hg.openjdk.java.net/jdk10/jdk10/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
>> [2] - 
>> http://hg.openjdk.java.net/jdk10/jdk10/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java#l48 
>>
>>
>>
>> Cheers
>> Maurizio
>>
>>
>


From peter.levart at gmail.com  Thu Jun 15 11:43:26 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 15 Jun 2017 13:43:26 +0200
Subject: [enhanced enums] - end of the road?
In-Reply-To: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
Message-ID: <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>

Hi Maurizio,

What if the enum type was kept non-generic, but there could optionally 
be a designated generic supertype inserted between the enum type and the 
constant type. For example:

public enum Option implements Consumer<String> super Generic {
     D<String>("-d", ...),
     PROC<ProcOption>("-proc", ...),
     ...;

     class Generic<T> implements Function<String, T> {
         Generic(...) {
             super(...);
         }

         public T apply(String s) {
             ...
         }
     }

     Option(...) {
         ...
     }

     public void accept(String s) {
         ...
     }
}


this would translate to:

public class Option extends Enum<Option> implements Consumer<String> {

     public static final Generic<String> D = new Generic<>("D", 0, "-d", 
...);
     public static final Generic<ProcOption> PROC = new 
Generic<>("PROC", 1, "-proc", ...);
     ...

     static class Generic<T> extends Option implements Function<String, T> {
         Generic(String name, int ordinal, ...) {
              super(name, ordinal, ...);
         }

         public T apply(String s) {
             ...
         }
     }

     Option(String name, int ordinal, ...) {
         super(name, ordinal);
         ...
     }

     public void accept(String s) {
         ...
     }
}


The "super" keyword in enum declaration could only designate a class in 
the same compilation unit - the enum member static class.

Hm...


Regards, Peter

On 05/23/2017 07:49 PM, Maurizio Cimadamore wrote:
> Hi,
> over the last few weeks we've been carrying out experiments to test 
> the feasibility of the enhanced enums feature. As described in the 
> JEP, this feature is particularly powerful as it allows enums 
> constants to be carrier of generic type information, which can then be 
> fed back to the inference machinery.
>
> One experiment we wanted to make was to see if enhanced enums could 
> make javac's own Option [1] enum better. This enum defines a bunch of 
> constants, one for each supported javac command line arguments (e.g 
> -classpath, -d, etc.). Furthermore, the enum defines method so that 
> each constant can be parsed given the javac command line and 
> processed, accordingly to some OptionHelper. Most options, along with 
> the value of their arguments would simply be stored into a Map<String, 
> String>, which is the backbone of the Options class [2].
>
> One problem with storing option values as Strings is that clients need 
> to do the parsing. So, if an option has an integer argument, it's up 
> to the client to get the value of that option off the map, parse it 
> into a number and (maybe) check as to whether the range makes sense.
>
> With enhanced enums it should be possible to do better than this; more 
> specifically, if enums supported generics, each option could specify a 
> type argument - that is, the type of the argument that javac expects 
> for that particular option.
>
> So, an option with a plain String argument would be encoded as 
> Option<String>, as follows:
>
> D<String>("-d", ...)
>
> While an option for which multiple choices are available, could be 
> encoded using an enum as a type-argument - for instance:
>
> PROC<ProcOption>("-proc", ...)
>
> where ProcOption would be defined as follows:
>
> enum ProcOption {
>    NONE, ONLY;
> }
>
> Finally, for an option whose argument can be a set of values, we would 
> use the following encoding:
>
> G_CUSTOM<EnumSet<DebugOption>>("-g:",  ...)
>
> where DebugOption would be defined as follows:
>
> enum DebugOption {
>     LINES, VARS, SOURCE;
> }
>
> So, instead of storing all options into a Map<String, String>, we 
> could store them into a Map<Option, Object>. Then, we would turn the 
> Options.get method from this:
>
> public String get(String option) { ... }
>
> to something like this:
>
> public Z get(Option<Z> option) { ... }
>
> granted, there will be some unchecked operations carried out by the 
> body of this method, but the map should be well-constructed by design, 
> so it should be safe. What we get back is that now clients can do 
> things like:
>
> boolean g_vars = options.get(Option.G_CUSTOM).contains(DebugOption.VARS);
>
> Note how we raised the expressiveness level of the client, which no 
> longer has to do parsing duties (and domain conversions). So, that was 
> the experiment we wanted to carry out - ultimately, this is the kind 
> of stuff you'd like to be writing with enhanced enums, so this seemed 
> like a reasonably comprehensive test for the feature.
>
>
> Unfortunately, the results of the experiment were not as successful as 
> we'd hoped. As soon as we turned the Option enum into a generic class 
> (by merely adding a type parameter in its declaration), we immediately 
> started hitting dozens of compile-time errors. The errors were rather 
> cryptic, all pointing to some obscure failure when calling 
> EnumSet.noneOf or EnumSet.allOf with the newly generified Option 
> class. In other words, code like this:
>
> EnumSet.noneOf(Option.class)
>
> Was now failing. The issue that was underpinning all these failures is 
> - in retrospect - rather obvious: the following type:
>
> EnumSet<Option>
>
> is *not* a well-formed type if Option is a generic class. Why? Well, 
> EnumSet is declared like this:
>
> class EnumSet<*E extends Enum<E>*> { ... }
>
> which means the type parameter has an f-bound. In concrete terms, we 
> have to check that:
>
> Option <: [E:=Option]Enum<E>
>
> That is, the actual type-argument must conform to its declared bound. 
> But if we follow that check, we obtain:
>
> Option <: [E:=Option]Enum<E>
> Option <: Enum<Option>
> Enum (*) <: Enum<Option>
> false
>
> (*) note that Option is now a 'raw' type - and a raw type has all 
> supertypes erased, as per JLS 4.8.
>
> In other words, there's no way to write down the type of an enum set 
> which contains heterogeneous options - the wildcard path doesn't help 
> either:
>
> EnumSet<Option<?>>
>
> As, the above check would develop in the following way:
>
> Option<?> <: [E:=Option<?>]Enum<E>
> Option<?> <: Enum<Option<?>>
> Enum<#CAP> (**) <: Enum<Option<?>>
> false
>
> (**) the supertype of a wildcard-parameterized type is obtained by 
> first capturing, and then recursing to the supertype, as per JLS 4.10.2
>
>
> In other words, generic enums are not interoperable with common data 
> structures such as enum sets (and, more generally, with any f-bounded 
> generic data structure).
>
> While we could just deliver the part of JEP 301 regarding sharper 
> typing of enum constants and leave generic enums alone, we feel 
> there's not much value into pursuing that path alone. After all, the 
> benefits of enhanced enums were exactly in combining sharper typing 
> with generic type information, so that enum constants could be used as 
> type carriers. If generic enums are not viable, then much of the 
> usefulness of this JEP is lost.
>
> It is unclear at this point in time if type system improvements (which 
> we are pursuing as part of a separate activity [Dan is there a link 
> for this??]) would ameliorate the situation.
>
> Until we figure this out, I suggest that we put this JEP on hold for 
> the time being
>
> [1] - 
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
> [2] - 
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java#l48 
>
>
>
> Cheers
> Maurizio
>
>


From peter.levart at gmail.com  Thu Jun 15 12:44:23 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 15 Jun 2017 14:44:23 +0200
Subject: [enhanced enums] - end of the road?
In-Reply-To: <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
 <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
 <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>
Message-ID: <9c5442ea-5c9c-da04-b5be-6255e1ed0a47@gmail.com>

Hi Maurizio,

On 06/15/2017 01:58 PM, Maurizio Cimadamore wrote:
>
> I think the moral equivalent of what you wanted to say is something 
> like this:
>
> enum Option implements Consumer<String> {
>    D implements Generic<String>("-d", ...) { ... }
>    PROC implements Generic<ProcOption>("-proc", ...) { ... }
>
>    ...
>
> }
>
> Which is not too terrible (in fact has been put forward by John as a 
> comment in the JEP [1]).
>

This is similar, but not the same. In above example, Generic<T> is not a 
subtype of Option. It's just an interface implemented by constant's 
subclasses. So you can not access Option members via an instance of 
Generic<T>... Generic<T> therefore has to declare all the interesting 
methods that can then be implemented by Option. You also have to 
accompany this solution with "sealed" interfaces if you don't want other 
implementations of Generic<T> besides the enum constants...

My example OTOH inserts a class between the enum type and the constant 
type which is designated by enum declaration and must be part of the 
same compilation unit (i.e. enum member static class). This middle class 
could have the same constraints regarding its constructor (must be 
private) as the enum constructor so no other class could subclass it or 
instantiate it. In effect it would be "sealed" by the virtue of 
constructor access modifier(s).

> That said, if we went down that path, note that, at least in my 
> re-formulation, there's no way to view Option as a subtype of Generic.
>

Or to view the Generic as subtype of Option...

> In other words, the enum as a whole would have nothing to do with 
> Generic, subtyping wise. Now, I think for the particular use case we 
> were considering, this could be still ok - at the end of the day we 
> wanted to write something like:
>
> public Z get(Option<Z> option) { ... }
>
> and in this model we could rewrite this as:
>
> public Z get(Generic<Z> option) { ... }
>
> One observation, if we had sealed interface, one could do this:
>
> enum Option implements Consumer<String> {
>
>     ...
>
>     sealed interface Generic<X> { ... }
> }
>
> so that the interface can only be effectively implemented by the enum 
> constants.
>
>
> So, what you're saying (or what I'm inferring from what you're saying 
> :-)) is: if we can't have generic on enums, having custom generic 
> supertypes on constants seems a pretty good approximation. Which is, I 
> think, a fair point.
>

Yes, but it would be nice for custom generic supertypes of constants to 
also be subtypes of enum type. This would have even more use cases.

Regards, Peter

> [1] - 
> https://bugs.openjdk.java.net/browse/JDK-8170351?focusedCommentId=14064981&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14064981
>
>
> On 15/06/17 12:43, Peter Levart wrote:
>> Hi Maurizio,
>>
>> What if the enum type was kept non-generic, but there could 
>> optionally be a designated generic supertype inserted between the 
>> enum type and the constant type. For example:
>>
>> public enum Option implements Consumer<String> super Generic  {
>>     D<String>("-d", ...),
>>     PROC<ProcOption>("-proc", ...),
>>     ...;
>>
>>     class Generic<T> implements Function<String, T> {
>>         Generic(...) {
>>             super(...);
>>         }
>>
>>         public T apply(String s) {
>>             ...
>>         }
>>     }
>>
>>     Option(...) {
>>         ...
>>     }
>>
>>     public void accept(String s) {
>>         ...
>>     }
>> }
>>
>>
>> this would translate to:
>>
>> public class Option extends Enum<Option> implements Consumer<String> {
>>
>>     public static final Generic<String> D = new Generic<>("D", 0, 
>> "-d", ...);
>>     public static final Generic<ProcOption> PROC = new 
>> Generic<>("PROC", 1, "-proc", ...);
>>     ...
>>
>>     static class Generic<T> extends Option implements 
>> Function<String, T> {
>>         Generic(String name, int ordinal, ...) {
>>              super(name, ordinal, ...);
>>         }
>>
>>         public T apply(String s) {
>>             ...
>>         }
>>     }
>>
>>     Option(String name, int ordinal, ...) {
>>         super(name, ordinal);
>>         ...
>>     }
>>
>>     public void accept(String s) {
>>         ...
>>     }
>> }
>>
>>
>> The "super" keyword in enum declaration could only designate a class 
>> in the same compilation unit - the enum member static class.
>>
>> Hm...
>>
>>
>> Regards, Peter
>>
>> On 05/23/2017 07:49 PM, Maurizio Cimadamore wrote:
>>> Hi,
>>> over the last few weeks we've been carrying out experiments to test 
>>> the feasibility of the enhanced enums feature. As described in the 
>>> JEP, this feature is particularly powerful as it allows enums 
>>> constants to be carrier of generic type information, which can then 
>>> be fed back to the inference machinery.
>>>
>>> One experiment we wanted to make was to see if enhanced enums could 
>>> make javac's own Option [1] enum better. This enum defines a bunch 
>>> of constants, one for each supported javac command line arguments 
>>> (e.g -classpath, -d, etc.). Furthermore, the enum defines method so 
>>> that each constant can be parsed given the javac command line and 
>>> processed, accordingly to some OptionHelper. Most options, along 
>>> with the value of their arguments would simply be stored into a 
>>> Map<String, String>, which is the backbone of the Options class [2].
>>>
>>> One problem with storing option values as Strings is that clients 
>>> need to do the parsing. So, if an option has an integer argument, 
>>> it's up to the client to get the value of that option off the map, 
>>> parse it into a number and (maybe) check as to whether the range 
>>> makes sense.
>>>
>>> With enhanced enums it should be possible to do better than this; 
>>> more specifically, if enums supported generics, each option could 
>>> specify a type argument - that is, the type of the argument that 
>>> javac expects for that particular option.
>>>
>>> So, an option with a plain String argument would be encoded as 
>>> Option<String>, as follows:
>>>
>>> D<String>("-d", ...)
>>>
>>> While an option for which multiple choices are available, could be 
>>> encoded using an enum as a type-argument - for instance:
>>>
>>> PROC<ProcOption>("-proc", ...)
>>>
>>> where ProcOption would be defined as follows:
>>>
>>> enum ProcOption {
>>>    NONE, ONLY;
>>> }
>>>
>>> Finally, for an option whose argument can be a set of values, we 
>>> would use the following encoding:
>>>
>>> G_CUSTOM<EnumSet<DebugOption>>("-g:",  ...)
>>>
>>> where DebugOption would be defined as follows:
>>>
>>> enum DebugOption {
>>>     LINES, VARS, SOURCE;
>>> }
>>>
>>> So, instead of storing all options into a Map<String, String>, we 
>>> could store them into a Map<Option, Object>. Then, we would turn the 
>>> Options.get method from this:
>>>
>>> public String get(String option) { ... }
>>>
>>> to something like this:
>>>
>>> public Z get(Option<Z> option) { ... }
>>>
>>> granted, there will be some unchecked operations carried out by the 
>>> body of this method, but the map should be well-constructed by 
>>> design, so it should be safe. What we get back is that now clients 
>>> can do things like:
>>>
>>> boolean g_vars = 
>>> options.get(Option.G_CUSTOM).contains(DebugOption.VARS);
>>>
>>> Note how we raised the expressiveness level of the client, which no 
>>> longer has to do parsing duties (and domain conversions). So, that 
>>> was the experiment we wanted to carry out - ultimately, this is the 
>>> kind of stuff you'd like to be writing with enhanced enums, so this 
>>> seemed like a reasonably comprehensive test for the feature.
>>>
>>>
>>> Unfortunately, the results of the experiment were not as successful 
>>> as we'd hoped. As soon as we turned the Option enum into a generic 
>>> class (by merely adding a type parameter in its declaration), we 
>>> immediately started hitting dozens of compile-time errors. The 
>>> errors were rather cryptic, all pointing to some obscure failure 
>>> when calling EnumSet.noneOf or EnumSet.allOf with the newly 
>>> generified Option class. In other words, code like this:
>>>
>>> EnumSet.noneOf(Option.class)
>>>
>>> Was now failing. The issue that was underpinning all these failures 
>>> is - in retrospect - rather obvious: the following type:
>>>
>>> EnumSet<Option>
>>>
>>> is *not* a well-formed type if Option is a generic class. Why? Well, 
>>> EnumSet is declared like this:
>>>
>>> class EnumSet<*E extends Enum<E>*> { ... }
>>>
>>> which means the type parameter has an f-bound. In concrete terms, we 
>>> have to check that:
>>>
>>> Option <: [E:=Option]Enum<E>
>>>
>>> That is, the actual type-argument must conform to its declared 
>>> bound. But if we follow that check, we obtain:
>>>
>>> Option <: [E:=Option]Enum<E>
>>> Option <: Enum<Option>
>>> Enum (*) <: Enum<Option>
>>> false
>>>
>>> (*) note that Option is now a 'raw' type - and a raw type has all 
>>> supertypes erased, as per JLS 4.8.
>>>
>>> In other words, there's no way to write down the type of an enum set 
>>> which contains heterogeneous options - the wildcard path doesn't 
>>> help either:
>>>
>>> EnumSet<Option<?>>
>>>
>>> As, the above check would develop in the following way:
>>>
>>> Option<?> <: [E:=Option<?>]Enum<E>
>>> Option<?> <: Enum<Option<?>>
>>> Enum<#CAP> (**) <: Enum<Option<?>>
>>> false
>>>
>>> (**) the supertype of a wildcard-parameterized type is obtained by 
>>> first capturing, and then recursing to the supertype, as per JLS 4.10.2
>>>
>>>
>>> In other words, generic enums are not interoperable with common data 
>>> structures such as enum sets (and, more generally, with any 
>>> f-bounded generic data structure).
>>>
>>> While we could just deliver the part of JEP 301 regarding sharper 
>>> typing of enum constants and leave generic enums alone, we feel 
>>> there's not much value into pursuing that path alone. After all, the 
>>> benefits of enhanced enums were exactly in combining sharper typing 
>>> with generic type information, so that enum constants could be used 
>>> as type carriers. If generic enums are not viable, then much of the 
>>> usefulness of this JEP is lost.
>>>
>>> It is unclear at this point in time if type system improvements 
>>> (which we are pursuing as part of a separate activity [Dan is there 
>>> a link for this??]) would ameliorate the situation.
>>>
>>> Until we figure this out, I suggest that we put this JEP on hold for 
>>> the time being
>>>
>>> [1] - 
>>> http://hg.openjdk.java.net/jdk10/jdk10/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
>>> [2] - 
>>> http://hg.openjdk.java.net/jdk10/jdk10/langtools/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java#l48 
>>>
>>>
>>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>
>


From peter.levart at gmail.com  Thu Jun 15 13:07:04 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 15 Jun 2017 15:07:04 +0200
Subject: [enhanced enums] - end of the road?
In-Reply-To: <9c5442ea-5c9c-da04-b5be-6255e1ed0a47@gmail.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
 <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
 <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>
 <9c5442ea-5c9c-da04-b5be-6255e1ed0a47@gmail.com>
Message-ID: <bbd29f4a-245a-4107-b0c6-ae9784f9e5db@gmail.com>



On 06/15/2017 02:44 PM, Peter Levart wrote:
>>
>> enum Option implements Consumer<String> {
>>    D implements Generic<String>("-d", ...) { ... }
>>    PROC implements Generic<ProcOption>("-proc", ...) { ... }
>>
>>    ...
>>
>> }
>>
>> Which is not too terrible (in fact has been put forward by John as a 
>> comment in the JEP [1]).
>>
>
> This is similar, but not the same. In above example, Generic<T> is not 
> a subtype of Option. It's just an interface implemented by constant's 
> subclasses. So you can not access Option members via an instance of 
> Generic<T>... Generic<T> therefore has to declare all the interesting 
> methods that can then be implemented by Option. You also have to 
> accompany this solution with "sealed" interfaces if you don't want 
> other implementations of Generic<T> besides the enum constants...

...in addition, you can not access/modify elements of EnumMap<Option, 
...> using keys of type Generic<T> for example - you would have to cast 
which is awkward given that your example use case:

public Z get(Generic<Z> option) { ... }

...would probably do just that...

Regards, Peter


From maurizio.cimadamore at oracle.com  Thu Jun 15 13:55:14 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 15 Jun 2017 14:55:14 +0100
Subject: [enhanced enums] - end of the road?
In-Reply-To: <bbd29f4a-245a-4107-b0c6-ae9784f9e5db@gmail.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
 <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
 <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>
 <9c5442ea-5c9c-da04-b5be-6255e1ed0a47@gmail.com>
 <bbd29f4a-245a-4107-b0c6-ae9784f9e5db@gmail.com>
Message-ID: <2c3f0b18-b9a2-e180-6a3a-8b7ba8e0e79f@oracle.com>

I get what you are saying. But I think this intermediate supertype feels 
too magic. After all, you're after a sneaky way to extend from an enum - 
which is not something you can do in the source code. If it was 
possible, then you could just add the supertype yourself

e.g.

enum Option {

D extends Generic<String>

...
}

where Generic would be defined as the translated code you wrote.

But since Generic cannot be written, you need to put that in the Option 
declaration, which seems untidy - in other words, if I look at the class 
declaration for Generic, there's nothing which tells me that it extends 
from Option, which is a big red herring IMHO (what if Generic is in a 
different sourcefile?). Also, you open up issues where changing your 
enum declaration is effectively changing the supertype of a (seemingly) 
unrelated class - meaning that if you have code outside which relied on 
that Generic class, you could break them w/o changing the definition of 
Generic.

That's why I think adding custom superinterfaces would be slightly 
tidier - as the information goes exactly in the place where you need it.


Regarding your point about casting with the 'get' method - well, it 
seems to me the cast would be internal to the API - so it's not 
something the client would see (e.g. the caller of 'get' would be able 
to pass the enum constant just fine).

Maurizio


On 15/06/17 14:07, Peter Levart wrote:
>
>
> On 06/15/2017 02:44 PM, Peter Levart wrote:
>>>
>>> enum Option implements Consumer<String> {
>>>    D implements Generic<String>("-d", ...) { ... }
>>>    PROC implements Generic<ProcOption>("-proc", ...) { ... }
>>>
>>>    ...
>>>
>>> }
>>>
>>> Which is not too terrible (in fact has been put forward by John as a 
>>> comment in the JEP [1]).
>>>
>>
>> This is similar, but not the same. In above example, Generic<T> is 
>> not a subtype of Option. It's just an interface implemented by 
>> constant's subclasses. So you can not access Option members via an 
>> instance of Generic<T>... Generic<T> therefore has to declare all the 
>> interesting methods that can then be implemented by Option. You also 
>> have to accompany this solution with "sealed" interfaces if you don't 
>> want other implementations of Generic<T> besides the enum constants...
>
> ...in addition, you can not access/modify elements of EnumMap<Option, 
> ...> using keys of type Generic<T> for example - you would have to 
> cast which is awkward given that your example use case:
>
> public Z get(Generic<Z> option) { ... }
>
> ...would probably do just that...
>
> Regards, Peter
>


From peter.levart at gmail.com  Thu Jun 15 14:43:33 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 15 Jun 2017 16:43:33 +0200
Subject: [enhanced enums] - end of the road?
In-Reply-To: <2c3f0b18-b9a2-e180-6a3a-8b7ba8e0e79f@oracle.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
 <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
 <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>
 <9c5442ea-5c9c-da04-b5be-6255e1ed0a47@gmail.com>
 <bbd29f4a-245a-4107-b0c6-ae9784f9e5db@gmail.com>
 <2c3f0b18-b9a2-e180-6a3a-8b7ba8e0e79f@oracle.com>
Message-ID: <e82a90f4-da0e-a9fa-ed43-068f29eff74a@gmail.com>

Hi Maurizio,

On 06/15/2017 03:55 PM, Maurizio Cimadamore wrote:
> I get what you are saying. But I think this intermediate supertype 
> feels too magic. After all, you're after a sneaky way to extend from 
> an enum - which is not something you can do in the source code. If it 
> was possible, then you could just add the supertype yourself
>
> e.g.
>
> enum Option {
>
> D extends Generic<String>
>
> ...
> }
>
> where Generic would be defined as the translated code you wrote.
>
> But since Generic cannot be written, you need to put that in the 
> Option declaration, which seems untidy - in other words, if I look at 
> the class declaration for Generic, there's nothing which tells me that 
> it extends from Option, which is a big red herring IMHO (what if 
> Generic is in a different sourcefile?).

The constraint would be that Generic can only be in the same compilation 
unit - i.e. as a static member class of the enum which designates it as 
a super type of constants. But I see your point - it would not have an 
"extends Option" clause in its declaration (the enum declaration would 
designate it as a subclass of enum type from the other way around), so 
it would be easy to misinterpret it.

> Also, you open up issues where changing your enum declaration is 
> effectively changing the supertype of a (seemingly) unrelated class - 
> meaning that if you have code outside which relied on that Generic 
> class, you could break them w/o changing the definition of Generic.
>
> That's why I think adding custom superinterfaces would be slightly 
> tidier - as the information goes exactly in the place where you need it.
>
>
> Regarding your point about casting with the 'get' method - well, it 
> seems to me the cast would be internal to the API - so it's not 
> something the client would see (e.g. the caller of 'get' would be able 
> to pass the enum constant just fine).
>
> Maurizio

...yeah, but the implementation of get would have to cast, meaning that 
there's something inadequate with the representation. Generics were 
meant to reduce the need of explicit casts.

I think there is a solution though which does not even require sealed 
interfaces. Take your example with Generic<T> as plain interface:

enum Option {
    D implements Generic<String>("-d", ...) { ... }
    PROC implements Generic<ProcOption>("-proc", ...) { ... }

    ...

}


...and then use the following method signature:

public <Z, O extends Option & Generic<Z>> Z get(O option) { ... }


Regards, Peter


>
>
> On 15/06/17 14:07, Peter Levart wrote:
>>
>>
>> On 06/15/2017 02:44 PM, Peter Levart wrote:
>>>>
>>>> enum Option implements Consumer<String> {
>>>>    D implements Generic<String>("-d", ...) { ... }
>>>>    PROC implements Generic<ProcOption>("-proc", ...) { ... }
>>>>
>>>>    ...
>>>>
>>>> }
>>>>
>>>> Which is not too terrible (in fact has been put forward by John as 
>>>> a comment in the JEP [1]).
>>>>
>>>
>>> This is similar, but not the same. In above example, Generic<T> is 
>>> not a subtype of Option. It's just an interface implemented by 
>>> constant's subclasses. So you can not access Option members via an 
>>> instance of Generic<T>... Generic<T> therefore has to declare all 
>>> the interesting methods that can then be implemented by Option. You 
>>> also have to accompany this solution with "sealed" interfaces if you 
>>> don't want other implementations of Generic<T> besides the enum 
>>> constants...
>>
>> ...in addition, you can not access/modify elements of EnumMap<Option, 
>> ...> using keys of type Generic<T> for example - you would have to 
>> cast which is awkward given that your example use case:
>>
>> public Z get(Generic<Z> option) { ... }
>>
>> ...would probably do just that...
>>
>> Regards, Peter
>>
>


From maurizio.cimadamore at oracle.com  Thu Jun 15 14:53:49 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 15 Jun 2017 15:53:49 +0100
Subject: [enhanced enums] - end of the road?
In-Reply-To: <e82a90f4-da0e-a9fa-ed43-068f29eff74a@gmail.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
 <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
 <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>
 <9c5442ea-5c9c-da04-b5be-6255e1ed0a47@gmail.com>
 <bbd29f4a-245a-4107-b0c6-ae9784f9e5db@gmail.com>
 <2c3f0b18-b9a2-e180-6a3a-8b7ba8e0e79f@oracle.com>
 <e82a90f4-da0e-a9fa-ed43-068f29eff74a@gmail.com>
Message-ID: <47ff9901-d445-d007-4c06-4cf5fc5db3fc@oracle.com>



On 15/06/17 15:43, Peter Levart wrote:
> Hi Maurizio,
>
> On 06/15/2017 03:55 PM, Maurizio Cimadamore wrote:
>> I get what you are saying. But I think this intermediate supertype 
>> feels too magic. After all, you're after a sneaky way to extend from 
>> an enum - which is not something you can do in the source code. If it 
>> was possible, then you could just add the supertype yourself
>>
>> e.g.
>>
>> enum Option {
>>
>> D extends Generic<String>
>>
>> ...
>> }
>>
>> where Generic would be defined as the translated code you wrote.
>>
>> But since Generic cannot be written, you need to put that in the 
>> Option declaration, which seems untidy - in other words, if I look at 
>> the class declaration for Generic, there's nothing which tells me 
>> that it extends from Option, which is a big red herring IMHO (what if 
>> Generic is in a different sourcefile?).
>
> The constraint would be that Generic can only be in the same 
> compilation unit - i.e. as a static member class of the enum which 
> designates it as a super type of constants. But I see your point - it 
> would not have an "extends Option" clause in its declaration (the enum 
> declaration would designate it as a subclass of enum type from the 
> other way around), so it would be easy to misinterpret it.
>
>> Also, you open up issues where changing your enum declaration is 
>> effectively changing the supertype of a (seemingly) unrelated class - 
>> meaning that if you have code outside which relied on that Generic 
>> class, you could break them w/o changing the definition of Generic.
>>
>> That's why I think adding custom superinterfaces would be slightly 
>> tidier - as the information goes exactly in the place where you need it.
>>
>>
>> Regarding your point about casting with the 'get' method - well, it 
>> seems to me the cast would be internal to the API - so it's not 
>> something the client would see (e.g. the caller of 'get' would be 
>> able to pass the enum constant just fine).
>>
>> Maurizio
>
> ...yeah, but the implementation of get would have to cast, meaning 
> that there's something inadequate with the representation. Generics 
> were meant to reduce the need of explicit casts.
>
> I think there is a solution though which does not even require sealed 
> interfaces. Take your example with Generic<T> as plain interface:
>
> enum Option {
>    D implements Generic<String>("-d", ...) { ... }
>    PROC implements Generic<ProcOption>("-proc", ...) { ... }
>
>    ...
>
> }
>
>
> ...and then use the following method signature:
>
> public <Z, O extends Option & Generic<Z>> Z get(O option) { ... }
>
>
Yes - that's even better :-)

Maurizio
> Regards, Peter
>
>
>>
>>
>> On 15/06/17 14:07, Peter Levart wrote:
>>>
>>>
>>> On 06/15/2017 02:44 PM, Peter Levart wrote:
>>>>>
>>>>> enum Option implements Consumer<String> {
>>>>>    D implements Generic<String>("-d", ...) { ... }
>>>>>    PROC implements Generic<ProcOption>("-proc", ...) { ... }
>>>>>
>>>>>    ...
>>>>>
>>>>> }
>>>>>
>>>>> Which is not too terrible (in fact has been put forward by John as 
>>>>> a comment in the JEP [1]).
>>>>>
>>>>
>>>> This is similar, but not the same. In above example, Generic<T> is 
>>>> not a subtype of Option. It's just an interface implemented by 
>>>> constant's subclasses. So you can not access Option members via an 
>>>> instance of Generic<T>... Generic<T> therefore has to declare all 
>>>> the interesting methods that can then be implemented by Option. You 
>>>> also have to accompany this solution with "sealed" interfaces if 
>>>> you don't want other implementations of Generic<T> besides the enum 
>>>> constants...
>>>
>>> ...in addition, you can not access/modify elements of 
>>> EnumMap<Option, ...> using keys of type Generic<T> for example - you 
>>> would have to cast which is awkward given that your example use case:
>>>
>>> public Z get(Generic<Z> option) { ... }
>>>
>>> ...would probably do just that...
>>>
>>> Regards, Peter
>>>
>>
>


From peter.levart at gmail.com  Thu Jun 15 16:12:36 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 15 Jun 2017 18:12:36 +0200
Subject: [enhanced enums] - end of the road?
In-Reply-To: <47ff9901-d445-d007-4c06-4cf5fc5db3fc@oracle.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
 <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
 <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>
 <9c5442ea-5c9c-da04-b5be-6255e1ed0a47@gmail.com>
 <bbd29f4a-245a-4107-b0c6-ae9784f9e5db@gmail.com>
 <2c3f0b18-b9a2-e180-6a3a-8b7ba8e0e79f@oracle.com>
 <e82a90f4-da0e-a9fa-ed43-068f29eff74a@gmail.com>
 <47ff9901-d445-d007-4c06-4cf5fc5db3fc@oracle.com>
Message-ID: <4b77efa1-93d0-1978-9edc-9cfcedee4fb3@gmail.com>



On 06/15/2017 04:53 PM, Maurizio Cimadamore wrote:
>> I think there is a solution though which does not even require sealed 
>> interfaces. Take your example with Generic<T> as plain interface:
>>
>> enum Option {
>>    D implements Generic<String>("-d", ...) { ... }
>>    PROC implements Generic<ProcOption>("-proc", ...) { ... }
>>
>>    ...
>>
>> }
>>
>>
>> ...and then use the following method signature:
>>
>> public <Z, O extends Option & Generic<Z>> Z get(O option) { ... }
>>
>>
> Yes - that's even better :-)
>
> Maurizio 

...but why stop there. Currently, it is not possible (in source code) to 
subclass enum(s) even though they are not technically final because 
constants can have custom subclasses. What is also enforced in source is 
that enum constructor(s) are implicitly private and that they can not be 
called explicitly. What if this subclassing constraint was lifted, but 
just the subclassing constraint - enum constructor(s) would still be 
enforced private and not explicitly callable except when chained from 
subclass. What this would amount to is that enum(s) could be subclassed 
by classes that are able to chain-call enum constructors - enum member 
classes (anonymous or local enum subclasses would be disallowed). If 
some enum member class subclassed the enum, its constructor(s) would get 
additional implied 'name' and 'ordinal' parameters and would fall under 
the same restriction as enum's constructor(s) - they would be implicitly 
and enforced private and not explicitly callable except when chained 
from subclass. This would amount to the following possibility:

public enum Option {

     D extends Generic<String>("-d", "default"),
     PROC extends Generic<ProcOption>("-proc", ProcOption.DEFAULT);

     public class Generic<T> extends Option {

         final T defaultValue;

         /* private */ Generic(String opt, T defaultValue) {
             super(opt);
             this.defaultValue = defaultValue;
         }
     }

     final String opt;

     /* private */ Option(String opt) {
         this.opt = opt;
     }
}

...the constants would optionally be able to extend any enum's subclass 
and/or implement any additional interfaces. There could be multiple enum 
subclasses (all constrained to be enum member classes) and each constant 
could independently choose to extend any one of them or none.

What do you think of that?

Regards, Peter


From maurizio.cimadamore at oracle.com  Thu Jun 15 17:15:37 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 15 Jun 2017 18:15:37 +0100
Subject: [enhanced enums] - end of the road?
In-Reply-To: <4b77efa1-93d0-1978-9edc-9cfcedee4fb3@gmail.com>
References: <786de6e1-8ca4-48ab-24b4-57460c232cef@oracle.com>
 <8cdd82b6-50c2-1913-44ac-560ea78ea6b3@gmail.com>
 <4c94d69e-aa91-e8f2-1460-a67a318ef253@oracle.com>
 <9c5442ea-5c9c-da04-b5be-6255e1ed0a47@gmail.com>
 <bbd29f4a-245a-4107-b0c6-ae9784f9e5db@gmail.com>
 <2c3f0b18-b9a2-e180-6a3a-8b7ba8e0e79f@oracle.com>
 <e82a90f4-da0e-a9fa-ed43-068f29eff74a@gmail.com>
 <47ff9901-d445-d007-4c06-4cf5fc5db3fc@oracle.com>
 <4b77efa1-93d0-1978-9edc-9cfcedee4fb3@gmail.com>
Message-ID: <345fe33f-395d-f2b0-7d52-643a35fe6133@oracle.com>

Again, I see where you are trying to go, but ultimately it feels a bit 
ad hoc, because the class you mention in the 'extends' clause is given a 
special meaning, and is probably subject to extra restrictions  - it 
must have constructor in a certain shape, it cannot override methods 
like name() etc. - and, again, these restrictions simply do not make 
sense if you look at the 'Generic' class declaration only.

Stepping back, while having custom generic supertypes is a nice trick to 
associate type information to enum constants, I also believe that, in 
terms of expressiveness, it is not the same thing as having full generic 
enums which can declare their own generic members. Granted, the client 
might not care too much if the members he can access are the same 
(although in some cases the client will have to use a different type 
than the enum one), but in terms of reading the resulting code (in which 
the state of the enum becomes spread across multiple places), I'm not 
sure if where we end up is better than where we started from.

Maurizio


On 15/06/17 17:12, Peter Levart wrote:
>
>
> On 06/15/2017 04:53 PM, Maurizio Cimadamore wrote:
>>> I think there is a solution though which does not even require 
>>> sealed interfaces. Take your example with Generic<T> as plain 
>>> interface:
>>>
>>> enum Option {
>>>    D implements Generic<String>("-d", ...) { ... }
>>>    PROC implements Generic<ProcOption>("-proc", ...) { ... }
>>>
>>>    ...
>>>
>>> }
>>>
>>>
>>> ...and then use the following method signature:
>>>
>>> public <Z, O extends Option & Generic<Z>> Z get(O option) { ... }
>>>
>>>
>> Yes - that's even better :-)
>>
>> Maurizio 
>
> ...but why stop there. Currently, it is not possible (in source code) 
> to subclass enum(s) even though they are not technically final because 
> constants can have custom subclasses. What is also enforced in source 
> is that enum constructor(s) are implicitly private and that they can 
> not be called explicitly. What if this subclassing constraint was 
> lifted, but just the subclassing constraint - enum constructor(s) 
> would still be enforced private and not explicitly callable except 
> when chained from subclass. What this would amount to is that enum(s) 
> could be subclassed by classes that are able to chain-call enum 
> constructors - enum member classes (anonymous or local enum subclasses 
> would be disallowed). If some enum member class subclassed the enum, 
> its constructor(s) would get additional implied 'name' and 'ordinal' 
> parameters and would fall under the same restriction as enum's 
> constructor(s) - they would be implicitly and enforced private and not 
> explicitly callable except when chained from subclass. This would 
> amount to the following possibility:
>
> public enum Option {
>
>     D extends Generic<String>("-d", "default"),
>     PROC extends Generic<ProcOption>("-proc", ProcOption.DEFAULT);
>
>     public class Generic<T> extends Option {
>
>         final T defaultValue;
>
>         /* private */ Generic(String opt, T defaultValue) {
>             super(opt);
>             this.defaultValue = defaultValue;
>         }
>     }
>
>     final String opt;
>
>     /* private */ Option(String opt) {
>         this.opt = opt;
>     }
> }
>
> ...the constants would optionally be able to extend any enum's 
> subclass and/or implement any additional interfaces. There could be 
> multiple enum subclasses (all constrained to be enum member classes) 
> and each constant could independently choose to extend any one of them 
> or none.
>
> What do you think of that?
>
> Regards, Peter
>