On 3 February 2012 13:33, Stéphane Ducasse <stephane.duca...@inria.fr> wrote: > > On Feb 3, 2012, at 12:20 PM, Nicolas Cellier wrote: > >> 2012/2/3 Lukas Renggli <reng...@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.
