Re: [Pharo-project] About linkedlist

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About linkedlist

Eliot Miranda-2
 


On Fri, Feb 3, 2012 at 6:18 AM, Lukas Renggli <[hidden email]> wrote:
>>>> 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?

No, it is a randomly chosen and meaningless name. I guess in the end
there will only be one named ArrayList, but I am not sure which
implementation is better.

Just a note to the VM developers: The primitive
Array>>#replaceFrom:to:with:startingAt: is absolutely central to the
implementation of efficient collections. While it works well if you
copy from one array to the other, it is broken if source and
destination array are the same and the areas overlap. Would it be
possible to fix this. Even "memmove(void*, void*, size_t)" in C can
handle this situation correctly.

The problems are that the primitive is defined to be destructive, and code could be depending on the destructive update behaviour.  Would it be feasible to use a new primitive that did the right thing in the case of overlap, or do you definitely want to change primitive 105?


>>>> 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 think it is pretty horrible. I can think of at least 4 meaningful
ways to iterate over an simple array (for other collections there are
even more ways):

   1. forward: #do:, #collect:, #select:, #detect:, #inject:into:, ...
   2. forward with index: #keysAndValuesDo:, #collectWithIndex:,
everything else is not possible
   3. backward: #reverseDo:, everything else is not possible
   4. backward with index: not possible

If you split the iterator into a separate object, suddenly all of this
becomes trivial. A #collect: remains a #collect: no matter if you are
going forward or backward, or with or without index.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] About linkedlist

Lukas Renggli

>> >>>> 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?
>>
>> No, it is a randomly chosen and meaningless name. I guess in the end
>> there will only be one named ArrayList, but I am not sure which
>> implementation is better.
>>
>> Just a note to the VM developers: The primitive
>> Array>>#replaceFrom:to:with:startingAt: is absolutely central to the
>> implementation of efficient collections. While it works well if you
>> copy from one array to the other, it is broken if source and
>> destination array are the same and the areas overlap. Would it be
>> possible to fix this. Even "memmove(void*, void*, size_t)" in C can
>> handle this situation correctly.
>
> The problems are that the primitive is defined to be destructive, and code could be depending on the destructive update behaviour.  Would it be feasible to use a new primitive that did the right thing in the case of overlap, or do you definitely want to change primitive 105?

A new primitive would be prefect. Like this we can even have a nice
fallback in case the VM doesn't have the primitive yet.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch