From jeremy.a.barrow at gmail.com Mon Aug 13 10:59:33 2018 From: jeremy.a.barrow at gmail.com (Jeremy Barrow) Date: Mon, 13 Aug 2018 12:59:33 +0200 Subject: Small things Java lets you do, but not everywhere. Message-ID: 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, ?> data = ...` It would be a massive boon, if we could write that as something like: `private static final Map, 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 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.