On 8 May 2010 02:07, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/5/8 Henrik Johansen <henrik.s.johansen@veloxit.no>:
As Nicolas described, linkedlists certainly have their usecases.
I think you might be blurring cause and effect when using is only used in process handling, as an argument why the easier-to-use, no noticeable performance overhead (but slightly more complex implementation wise) version should be reverted.
Cheers, Henry
Personnally, I like a LinkedList being able to hide the Link the way Dictionary hides the Association.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117262.html http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004835.html
yeah, i think its protocol could have two entry points: - #add: for adding an object to list - #addLink: for linking a link to list so, that, #add: always creates a new instance of ValueLink , without asking object to do #asLink and then sends #addLink: , which does the rest.
Nicolas
Den 8. mai 2010 kl. 00.06 skrev Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2010/5/8 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2010/5/7 Igor Stasenko <siguctua@gmail.com>:
On 7 May 2010 23:47, Lukas Renggli <renggli@gmail.com> wrote:
He had the idea that it would be nice to be able to add any object to a LinkedList, instead of just Link subclasses. (IIRC, 'like you can in Ruby' ;))
So we added ValueLink as the common pattern for "A link with an object in it", which is now the default if you add an object which itself is not a link.
Makes it much more convenient to actually use a LinkedList, ref. f.ex. the Stack implementation.
LinkedList is used internally by the process scheduler to handle processes, I don't think that it is ment to be used as a public collection class. For probably all applications it is slower and uses more memory than an OrderedCollection.
+1. OrderedCollection's addLast/removeFirst/removeLast, is enough to use them as lists.
About performance, i am little concerned. Linked lists is good , that is costs you a constant time for each new element you adding. While for OrderedCollections it vary depending on container state. In most cases, it costs you as little as for linked lists, but when contained is not big enough to hold all elements - then it has to grow and consuming a lot more time comparing to adding a previous element.
Yes, LinkedList is most interesting when you add:after:/remove: in between... OrderedCollection also isn't at best when used as FIFO because repeted addLast/removeFirst will trigger a makeRoomAtLast. It might be better to handle a cyclic index. For example, I would maintain firstIndex and size in inst vars:
addLast:anObject  array size > size ifFalse: [self grow].  array atWrap: firstIndex + size put: anObject.  size := size + 1.  ^anObject
removeFirst  | firstObject |  self emptyCheck.  firstObject := array at: firstIndex.  array at: firstIndex put: nil.  firstIndex := firstIndex \\ array size + 1.  size := size - 1.  ^firstObject
grow  | grown end |  grown := Array new: array size + self growSize.  end := (firstIndex + size - 1 min: array size) - firstIndex + 1.  grown replaceFrom: 1 to: end with: array starting at: firstIndex.  grown replaceFrom: end +1 to: size with: array startingAt; 1.  array := grown
Oops, forgot  firstIndex := 1
Of course, you still pay the grow...
Nicolas
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.