Its interesting, since in many places i using in-line linked list implementation,
without troubling subclassing from "certified" LinkedList (or friends).

This thing is a good case for stateful trait ('next' ivar + accessors and some logic for iterating etc).
Unfortunately, for efficiency reasons, and since we're lacking stateful trait support,
it is cheaper to simply implement such pattern in place rather than reusing existing implementation. In most cases i simply using key part - links between items, and don't see a need of inheriting hundreds of methods (sure sure, each�� time you inherit, it gives you 1000+1 way of (re)using that toy without writing a code, right?). Less is more :)

I wonder, if i would be tempted to reuse LinkedList , if its implementation would be less horrible than it is now :)
===

As for difference between stack and linked list implementation, apart from being different paradigms, i see it as following:
�� linked list basically 'declares' that items can easily access neighboring ones through direct reference (hence links),
in stack, there's no any assumption whether items be able to see each other or not.

For single linked list, it requires tracking only head. For efficiency, one might track tail pointer as well, but it is not necessary for correct implementation.
Also, linked list structure allows very quick (O(1)) implementation for insertion/deletion items in the middle of it.
While for stack, inserting/deleting in the middle is a nonsense. And i would really execute anyone who using such behavior simply because Stack is a subclass of LinkedList :)

IMO, for stack a more efficient memory structure would be
[ buffer array of items ] + stack pointer.
As benefit, accessing items down the stack will be a simple indexing O(1) procedure, which is sometimes useful. Apparently, linked list is less efficient in this regard, since it will require interation.

The (ever) growing array size is not an issue here, since by its purpose, stack serves as a special data exchange structure, that dynamically pipes things through itself, and always consumed fully at the end. So we can expect that
��most algorithms is normally very quickly settling down with stack max size, and then there's no need for frequent reallocation of stack buffer.
I would also expect that stacks are never too deep: if it is, this might be an indication of using wrong data structure.




On 2 July 2015 at 23:26, stepharo <stepharo@free.fr> wrote:


Le 30/6/15 20:25, Thierry Goubier a ��crit :
Le 30/06/2015 19:27, stepharo a ��crit :
alain fixed in place edit for string morph so we could even rename a
protocol simply by double clicking on it.

I noticed years ago that I could get that for free in a MorphTreeMorph by using a text instead of a string in the node description: would give you many, many types of renames, not only protocols.

But this is another story

Yes and no. There are complaints about the model, and when you see the state of the tools... you can't be impressed by the fact it wasn't improved a long time ago.

Indeed this is several weeks that we are with Franck fighting with Nautilus and others. But day after day we are making progress.


But maybe like that it makes some tools look better.

Thierry







--
Best regards,
Igor Stasenko.