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 <[email protected]> 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.
