On 3 February 2012 13:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Feb 3, 2012, at 12:20 PM, Nicolas Cellier wrote:
2012/2/3 Lukas Renggli <renggli@gmail.com>:
This is all very much at an experimental phase.
what is the diff between arrayList and vectorList ?
ArrayList is double ended (very much like OrderedCollection), VectorList is single ended. I was just experimenting to see if it makes a difference.
ok. I like to see such kind of experiment. Was the name based on something that people use?
Do you have some kind of high level description of Container explaining the rationale, ideas and approach.
The core idea is to split iteration from containment; I think a horrible design mistake in the Smalltalk-80 collections.
I thought about that when I read the Iterator. I would not say that this is horrible. I think that for default case this is not that bad. Now when you want to navigate a large graph and control the navigation then you should have an iterator.
I'm curious to see what you will get.
Do you have some kind of high level description of Container explaining the rationale, ideas and approach. It is one thing to browse the code, but the why/how is important as a guide.
Another idea is to split the backing store from the container and allow the composition of collection properties:
 - uniqueness: yes, no  - order: natural, custom, indexed  - access: indexed, keyed  - structure: hashed, treed, linked  - weakness: yes, no (not even touched yet)
Yes I as to see that because I often want uniqueOrdered (not clear what you do when you add twice the same)
It seems that although you introduce iterators, they are less annoying then expected, which is great.
The goal here is to be as lazy as possible and avoid unnecessary loops over the collections.
Also iterators avoid the explosion of selector combinations like (#do: and #withIndexDo: and #withIndexCollect:, etc) by utilizing objects.
Also, a certain level of backwards compatibility seems to be present, looking at message names.
I like the existing names, but then this is not a goal. Also I am not sure if methods like #add: and #at:put: should really return the argument.
:) If I would know :)
it is somewhat convenient, because you can do things like: newItem := coll at: index ifAbsentPut: [ MyItem new ]. and other such forms...
Stef
-- Best regards, Igor Stasenko.