Language support for collections about eo

[SilasReinagel]

I don't think the goal is to deprive developers of important abilities. The goal is to simplify the common use cases.

So, maybe there should be a way to specify a name for plural and the type of structure used. If unspecified, a default could be inferred.

Furthermore, many collection functionalities could be added via decoration. Colors appColors = unique(colors(white, black)) would behave like a Set instead of a List.

[yegor256]

@SilasReinagel I was waiting for this ticket. Thanks!

[scadgek]

There is a reason behind separate collection classes - they're backed by different data structures. How do you suggest to implement this variety in colors?

[pchmielowski]

@scadgek Maybe in some inverted-Java-way: Colors appColors = colors<LinkedList>(white, black)
And if user does not provide < ... > block, compiler will choose the default structure.

[yegor256]

@pchmielowski we have arrays in Java, but don't have collections. This is sort of legacy from C/C++. And I'm mostly thinking about iterables, not collections. How exactly that lists, queues, sets, maps, etc will be implemented is up to JDK (EDK maybe). But we have to have that "iterable" thing built into the language, I believe.

[scadgek]

@yegor256 So if I understand you correctly, you consciously deprive the developers of the ability to choose the underlying data structure?

[stain]

I think we can take inspiration from Java 8 streams here, where the type of collection you want comes about later and just modulate the stream, e.g. unordered(gradient(colors(white, black), 0.1)) to get an unordered stream from a color gradient with a 0.1 increase.

[yegor256]

@stain we have array object now, which is an immutable primitive collection with random access.

[0crat]

Job gh:cqfn/eo#8 is not assigned, can't get performer