Another detail is that LinkedList's design is heavily tied to the VM. Our linked list implementation can contain any object that *looks like a link*, meaning��
- in the higher level they have to understand the message nextLink and nextLink:
- in the lower level, if it is a linked list used by the VM, the nextLink should be the first inst var of the object.

What I mean with this is that we should be careful when changing linked list. Changing its internal representation may crash your image ^^.

El mar., 30 de jun. de 2015 a la(s) 11:10 a. m., Max Leske <maxleske@gmail.com> escribi��:

> On 30 Jun 2015, at 11:00, stepharo <stepharo@free.fr> wrote:
>
>
>
> Le 28/6/15 19:00, Sven Van Caekenberghe a ��crit :
>>> On 28 Jun 2015, at 17:59, Max Leske <maxleske@gmail.com> wrote:
>>>
>>>
>>>> On 28 Jun 2015, at 17:22, stepharo <stepharo@free.fr> wrote:
>>>>
>>>> Hi guys
>>>>
>>>> is there a real reason for Stack being a subclass of LinkedLink?
>>> 1. You don���t need to adjust an internal data structure (grow, shrink, move, sort) to update the stack but only move references.
> But it is used in practice?
> Because Stack could use a LinkedList and you get the same benefits and not stupid methods that do not make sense for Stack.

agreed.

>
>>> 2. The interface is pretty similar
>
> No there are not :)
> Stack is push pop top not insert after:.....
> or this is a strange stack.

What I meant was: Linked list provides an interface that allows for stack operations. Not that the naming conventions are the same.

>> 3. It is an implementation detail/technique, it is indeed not as if Stack is-a LinkedList (from that point of view it is confusing)
>
> What I mean is that this is not good to have subclassing when we can use subclassing.
> We remove the fact that Dictionary is a subclass of Set for this reason.
>

You asked for reasons. I didn���t say they were *good* reasons :)

>>
>>>> Stef
>>>>
>>>
>>
>>
>
>