De: "Brian Goetz" <brian.go...@oracle.com>
À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
Envoyé: Mardi 21 Août 2018 13:57:51
Objet: Fwd: Small things Java lets you do, but not everywhere.
BQ_BEGIN
Received via the spec-comments list. Not a comment on any specific extant
project; instead, a wish-list, and mostly stuff we’ve seen before — array
literals, generic maps, union types.
BQ_END
- array literals
we already have them no ?
new int[] { 2, 3, 5};
if you mean supported in the bytecode, yes, we are working on that as a follow
up of ConstantDynamic.
- generics/parameterized fields
i occasionally want that but mostly to workaround the fact that generics are
not fully reified. If we stick with erasure, i do not see any theoretical
issue, with reified generics that we want to introduce as part of valhalla, it
means that getfield/getstatic also have their semantics overriden to do a cast
at least when writing to verify the constraint.
Now, Java has a kind of pragmatic support of generics, not every constructs are
supported because it can be. Parameterized fields (like lambda support of
parameterized methods) falls in that category in my opinion.
- union types
technically, we already have union types but only for exceptions.
@jeremy in your message you mix union like in C and union type that are not
exactly the same thing.
For union like in C, the obvious answer is to use an interface instead, with
sealed interface, record and value types you can have something similar to an
union,
by example a Token of a lexer can be see as:
value record Token(String data, Type type);
sealed interface Type {
enum Primitive implements Type { INT, DOUBLE };
record UserDefined(String name) implements Type;
}
For union types, in Java 5 it was decided to use lub (the lower upper bound)
instead of the union between two types, i think destroy any hope to have union
type in Java even if the type system of Ceylon and now Scala 3 (Dotty) clearly
shows that it's a better idea.
regards,
Rémi
BQ_BEGIN
BQ_BEGIN
Begin forwarded message:
From: Jeremy Barrow < [ mailto:jeremy.a.bar...@gmail.com |
jeremy.a.bar...@gmail.com ] >
Subject: Small things Java lets you do, but not everywhere.
Date: August 13, 2018 at 6:59:33 AM EDT
To: [ mailto:amber-spec-comme...@openjdk.java.net |
amber-spec-comme...@openjdk.java.net ]
Heyo, I just wanted to send off a quick email about some of the things that
I think would be easy pickings for Amber to tackle.
More specifically, they're things in the language that are either not
completely fleshed out due to lack of interest, or, more likely, for some
technical reason.
The first one is definitely array literals:
I've been using Java for 7ish years at this point, and honestly, I don't
even know if I'm gonna get this right.
The only place I'm aware of array literals being valid is for a field write.
Not many people use arrays, as Lists are just better, but _very_
occasionally you do have to reach for an array.
It would be nice if we could expand the array literal use case.
Just about everywhere an expression could be expected, I think an array
literal could be valid.
I can image `return` statements working really well with it, and with the
new expression switch, the break with value.
I'll be honest, this is where the "easy pickings" part is no longer true.
Class local generics (Field local generics?):
I definitely think I'm not the only one who has written some static field
that has a map which maps some arbitrary data container to some value, with
the data container containing some type parameter that tells you what the
value type is.
`private static final Map<Key<?>, ?> data = ...`
It would be a massive boon, if we could write that as something like:
`private static final <T> Map<Key<T>, T> data = ...`
Otherwise we have to cast everything we pull out of the map.
I know it's of the correct type, but the compiler doesn't.
This leads to some annoying stuff where generics aren't actually helping
you, which is a bit counter intuitive.
We have generics for methods, theoretically, it should be possible for
fields.
Union types:
Now, I'll preface this with this might be difficult to translate into the
VM right now, so erasure might be the only option for now (With type
signatures being a possible route in the future).
In a nutshell, declaring fields with union types.
Right now, I either have to declare three different fields, making my
memory usage suffer if I have tons of these objects (Which I normally do,
because this specific class is a Token class for a lexer, and I parse
massive input sources), also making it more error prone due to having three
different ways to access the same data.
Granted union types won't solve the last problem, but it doesn't help it.
Technically, Java does have union types in catch signatures.
Obviously, the catch signatures kinda get "collapsed", so it's not really
the same, as there's a lot more needed under the hood here.
Possibly.
I think a quick prototype might be just to treat it as though I had written
something like, and just erase it to Object:
`private final <T extends String | Integer | Double> T data;`
Obviously, we don't have union generics, so that would obviously have to be
added, and honestly, I think that might be the can of worms I didn't plan
on.
So, I'll wrap it up there.
Obviously, the generics and union types are quite.. large in scope, and
aren't really easy, but I do think the array literals are something that
could be touched on.
Cheers,
Jeremy.
BQ_END
BQ_END
