Den 8. mai 2010 kl. 01.20 skrev Igor Stasenko <siguc...@gmail.com>:
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.
I don't quite see the appeal in an approach which both has a more
complicated protocol, and is backwards-incompatible.
Cheers,
Henry
PS. We DID consider other possible solutions before deciding to add
"yet another" as... method to Object
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
