JEP 186: Collection Literals
Jochen Theodorou
blackdrag at gmx.org
Fri Jan 31 02:33:33 PST 2014
Am 31.01.2014 10:02, schrieb Remi Forax:
> On 01/31/2014 09:59 AM, Jochen Theodorou wrote:
>> Am 31.01.2014 09:43, schrieb Remi Forax:
>> [...]
>>> If one day the JDK has persistent collections (and I hope it will),
>>> there will be not interface to abstract them.
>>> (you can still ask all implementations in the javadoc of the interface
>>> to super swear that they are immutable but it's a weak contract).
>>
>> But the same goes for an abstract base class. So those persistent
>> collections would always have to have only the concrete class and most
>> probably no super class besides Object.
>>
>> Supporting different implementations then becomes difficult.
>
> if the abstract class is public, yes, but you can make it non public,
> like by example the abstract class between StringBuilder and StringBuffer.
I may not have said it right... implementation wise you can do a lot
with a delegation model if you have to and not use inheritance. So for
implementing those classes it is most probably not a problem.
I was thinking of the user side. For example let's say there is an
implementation of a persistent list (or set) with a contains method.
There are different possible implementations for that. But if there is
no abstraction of the type anymore, the user code can only depend on a
concrete type.
You can move different implementations into a single class. Then, the
"instantiator" of the instance could choose the implementation by
argument for example. The problem is, that this does not allow user
implementations at all.
I use for example a hash array mapped trie as persistent map. There are
sure other implementations that make sense out there in for other
scenarios. It would not be feeling right, not allowing user
implementations at all
bye Jochen
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
More information about the lambda-dev
mailing list