On 8 May 2010 02:07, Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> wrote: > 2010/5/8 Henrik Johansen <henrik.s.johan...@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.n...@gmail.com>: >> >>> 2010/5/8 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com>: >>>> >>>> 2010/5/7 Igor Stasenko <siguc...@gmail.com>: >>>>> >>>>> On 7 May 2010 23:47, Lukas Renggli <reng...@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. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
