Hi Remi, some comments inline.
On 05/12/2018 21:43, Remi Forax wrote:
Hi Maurizio,
i think you have overlook the fact that raw types and inference also doesn't
play well together.
As I said, I've played with this quite a bit and came out convinced that
usability wise it's good. Note that in the proposed model, enum
constants will have full generic types - e.g. Foo<String>; it's only
when you go to the supertype that the type system will say Enum<Foo>.
But this will only be used by APIs accepting some Enum<T> - so we're
fine, and this actually guarantees same inference results as before
generification of a given enum.
accessibility:
Widening the type is usually a big No because of the security implication. The
fact that the same code code has no security bug with version n but a security
hole with version n + 1 scares me.
What scenario do you have in mind regarding enum constant pseudo-inner
classes?
source compatibility:
It's may not be a big issue because the JDK source doesn't use 'var'. If a code
uses 'var' the sharp type will propagate more, so the JDK is not perhaps the
best code to test.
friend or foe:
the rules for raw types are brutal as you said, but it's by design, it offers
maximum compatibility and doesn't allow to mix raw and generic type easily so
my students detect the missing angle brackets easily (IntelliJ still doesn't
warn about missing angle brackets by default :( )
Now about your example, instead of being functional and wanted each Option to
type their argument, you can use ugly side effects instead.
So the idea is to use a temporary class instead of a Map to store the data
associated with an option. So an Option is something that takes a chunk of the
command line arguments and do a side effect on the field of an instance of that
temporary class.
Sure, there might be other ways to get there; what I did, I did it to
test usage of generic enums in a real world code base.
Maurizio
public class LineParsing {
private final HashMap<String, Consumer<? super Iterator<String>>> actionMap = new
HashMap<>();
public LineParsing with(String option, Consumer<? super Iterator<String>> action) {
actionMap.put(option, action);
return this;
}
public void parse(List<String> args) {
var it = args.iterator();
while(it.hasNext()) {
actionMap.get(it.next()).accept(it);
}
}
public static void main(String[] args) {
var bean = new Object() {
Path input = Path.of("input.txt");
boolean all = false;
};
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" <maurizio.cimadam...@oracle.com>
À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
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 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 greater details here:
http://cr.openjdk.java.net/~mcimadamore/amber/enhanced-enums.html
We have done some internal testing to convince ourselves that, from an
operational perspective, where we end up is indeed good. Some external
validation might also be very helpful, which is why we're also in the
process of releasing the internal patch we have tested internally in the
'enhanced-enums' amber branch (we'll need to polish it a little :-)).
Assuming that, usability-wise, our story ticks all the boxes, I think it
might be worth discussing a few points:
* Do we still like the features described in JEP 301, from an
expressiveness point of view?
* Both features described in JEP 301 require some sort of massaging. On
the one hand sharper typing of enum constants has to take care of binary
compatibility of enum constant subclasses into account (for this reason
we redefine accessibility of said subclasses along with their binary
names). On the other hand, with the newly proposed approach, generic
enums also need some language aid (treatment of raw enum constants
supertypes). Do we feel that the steps needed in order to accommodate
these sharp edges are worth the increase in expressive power delivered
by JEP 301?
* 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)?
Cheers
Maurizio
[1] -
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-May/000041.html
