reinier at zwitserloot.com
Mon Mar 16 06:22:06 PDT 2009
Of all those items, list comprehensions and list literals rank -far-
higher on my 'general utility' meter than any of the other ones, but
almost all of them seem doable with a minimum of JLS munging.
list comprehensions, /IF/ they produce a complete list and not a
lazily evaluating iterable, is just syntax sugar. If they do apply
lazy evaluation, it inherits most of the problems closure proposals
try to deal with. Serious doubts about suitability for Project Coin in
the latter case. Suggestion:  makes complete lists, there's always
the opportunity to introduce a slightly alternative syntax in the
future when/if closures show up in java8 and those issues have already
been solved - then an iterable based list comprehension is just syntax
sugared into something involving closures for the generator and filter
List literals are equally complicated; the complication lies in
correctly parsing a new construct, such as 'stuff in between array
brackets that does not appear after an expression (because that would
be array index lookup)' - presuming for a moment that list
comprehensions use  as well.
array style access for lists, maps, and strings: I believe Joe D'Arcy
posted it as a suggestion at the announcement of coin-dev. Support
from the community has been tepid at best, but in combination with
comprehensions and slices, I'd be in favour. Much more difficult for
maps (right now brackets-after-expression wants an integer inside the
brackets. You'd be changing this for maps to be a K instead). Proposal
without bracket access for maps would still sound good to me. I don't
use list.get(X) very often, though...
negative array indices should count backwards: Utterly impossible for
arrays. Would break backwards compatibility (foo[-1] should produce an
ArrayIOOBException, people will be relying on that). The notion that
many things in java return -1 to indicate 'not found' (such as
String.indexOf) makes this idea a bit more complicated than it might
seem at first glance, and the idea you could only apply it to Lists,
not arrays, would be an unfortunate inconsistency. I say: skip this one.
slices: What type of list should roll out? A generic immutable
List<T>, regardless of what you sliced on? If so, trivial syntax
sugar: Add a library that produces a sliced list given as input a list
and 2 numbers, then rewrite all slices to a call to this library. Also
offers a sneaky way to get the last item in a list without -1 syntax:
list[-1:0]. Alternative outputs: A bound view (which just remembers
start index and size, and continues to call .get(X+offset) into the
original list), which would mean removing an item in the original list
removes it from the sliced list. Such a bound view could support being
mutable, but that would introduce even more weirdness: Removing an
item from the original does not shrink the bound view, but removing it
via the bound vie DOES shrink the bound view. Meh. I strongly suggest
making slicelists immutable copies to avoid this mess.
autoboxing arrays to lists and vice versa: Because they share part of
their inheritance tree (specifically: java.lang.Object), that would
get very confusing, very fast. There's also the issue of covariance:
Can you autobox an ArrayList<T> to a List<List<T>>? Again, type
issues. I doubt this one is worth it.
On Mar 16, 2009, at 11:37, Vilya Harvey wrote:
> 2009/3/14 Reinier Zwitserloot <reinier at zwitserloot.com>
> So what proposals are still fermenting in the minds of coin
> contributors? Inspired by the recent discussion between Joe D'Arcy and
> Mark Mahieu that people are possibly thinking someone else will be
> proposing it.
> I had a few things in mind, mostly to do with lists, some of which
> people have already mentioned:
> list comprehensions.
> either list literals or autoboxing/unboxing conversions between
> arrays and lists (I haven't really thought this one through yet; I
> suspect there would be a lot of issues in deciding when to apply the
> array style access for lists, maps and strings.
> negative array indexes should count from the back of the array (e.g.
> a[-1] == a[a.length - 1]).
> slice syntax a la python for arrays, lists and strings.
> I'll happily write any of these up, if anyone thinks there'd be
> enough interest.
More information about the coin-dev