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

Reply via email to