JEP 186: Collection Literals

[Richard Warburton]

Hi,

Is there any real reason to restrict the proposal to implementing any
>> specific interface? It seems preferable to able to specify some kind of
>> recipe or factory for building an arbitrary concrete type out of a
>> collection literal. This could then be associated with the class it
>> constructs through a mechanism such as a ClassValue.
>>
>
> That's exactly what I meant by "how far do we go".  The extremes of this
> axis are "set/list/map/array only" at one end and at the other, a fully
> general pluggable mechanism for initialization that could support things
> like Json literals with nested target typing (i.e., a list-like literal
> inside a Json list would be target-typed to a Json list), initialization of
> JavaBean classes using map-like literals, static binding of map-like
> literals to constructors (giving the appearance of named parameters,
> presumably with some concept of symbol), etc.  This feature could be very
> small or very big.
>
> Now, you might ask, why would we choose the simple thing when we could
> choose the grand and abstract?  To re-re-re-state the obvious, modifying
> the language is insanely expensive, and I don't just mean it costs Oracle a
> lot of money.
>

I was actually asking if there was a technical reason. That's not to say
that I'm disagreeing with or dismissing any of your analysis about the
costs of language change, which I appreciate you are far better placed than
me to assess. I was merely trying to identify whether you saw an upper
bound on the scope of the proposal which the JEP is investigating before
thinking through the cost:benefit tradeoffs of different proposals.

For example, how long would you have been willing to delay Lambda to make
> collection literals better?  I suspect (and hope) the answer is "none at
> all".  It almost always is a choice of "this or something else."


Obviously that would be my answer. I think some people would prioritise it
over lambdas, because one is a feature that needs advocacy and the other
one has more transparent benefit.

I'll also add that speaking for purely for myself, I would probably not
value delaying primitive specialisation in generics or value types in
favour of syntactic sugar.  I'm willing to wager money that if you asked
most Java developers they would take the sugar over the fundamentals. I'm
not suggesting you such be making your judgement on such a basis, merely
observing that collection literals are a popular request.


>  It would be a shame to privilege core library
>> classes over third party ones in this regard.
>>
>
> This is a powerful consideration, and another aspect of my "how far"
> question.  The rational thing might actually be to do nothing here. Because
> we may well have a choice of doing something that is assymmetric and hacky,
> but small enough to actually do without upsetting the applecart, or
> something that is symmetric and pleasingly abstract, but not remotely as
> important as the things it might push off the plate.


Ack.

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>