<br><br><div class="gmail_quote">On Fri, Feb 3, 2012 at 6:18 AM, Lukas Renggli <span dir="ltr"><<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>>>> what is the diff between arrayList and vectorList ?<br>
>>><br>
>>> ArrayList is double ended (very much like OrderedCollection),<br>
>>> VectorList is single ended. I was just experimenting to see if it<br>
>>> makes a difference.<br>
><br>
> ok. I like to see such kind of experiment.<br>
> Was the name based on something that people use?<br>
<br>
</div>No, it is a randomly chosen and meaningless name. I guess in the end<br>
there will only be one named ArrayList, but I am not sure which<br>
implementation is better.<br>
<br>
Just a note to the VM developers: The primitive<br>
Array>>#replaceFrom:to:with:startingAt: is absolutely central to the<br>
implementation of efficient collections. While it works well if you<br>
copy from one array to the other, it is broken if source and<br>
destination array are the same and the areas overlap. Would it be<br>
possible to fix this. Even "memmove(void*, void*, size_t)" in C can<br>
handle this situation correctly.<br></blockquote><div><br></div><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>>>> Do you have some kind of high level description of Container explaining the rationale, ideas and approach.<br>
>>><br>
>>> The core idea is to split iteration from containment; I think a<br>
>>> horrible design mistake in the Smalltalk-80 collections.<br>
><br>
> I thought about that when I read the Iterator.<br>
> I would not say that this is horrible. I think that for default case this is not that bad.<br>
> Now when you want to navigate a large graph and control the navigation then you should have an iterator.<br>
<br>
</div>I think it is pretty horrible. I can think of at least 4 meaningful<br>
ways to iterate over an simple array (for other collections there are<br>
even more ways):<br>
<br>
1. forward: #do:, #collect:, #select:, #detect:, #inject:into:, ...<br>
2. forward with index: #keysAndValuesDo:, #collectWithIndex:,<br>
everything else is not possible<br>
3. backward: #reverseDo:, everything else is not possible<br>
4. backward with index: not possible<br>
<br>
If you split the iterator into a separate object, suddenly all of this<br>
becomes trivial. A #collect: remains a #collect: no matter if you are<br>
going forward or backward, or with or without index.<br>
<br>
Lukas<br>
<font color="#888888"><br>
--<br>
Lukas Renggli<br>
<a href="http://www.lukas-renggli.ch" target="_blank">www.lukas-renggli.ch</a><br>
<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>