Hi Maurizio,
i think you have overlook the fact that raw types and inference also doesn't
play well together.
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.
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.
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
