Stack
Locked
12
12
 
|
Hi guys
is there a real reason for Stack being a subclass of LinkedLink? Stef |
|
|
> On 28 Jun 2015, at 17:22, stepharo <[hidden email]> 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. 2. The interface is pretty similar > > Stef > |
|
|
> On 28 Jun 2015, at 17:59, Max Leske <[hidden email]> wrote: > > >> On 28 Jun 2015, at 17:22, stepharo <[hidden email]> 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. > 2. The interface is pretty similar 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) >> >> Stef >> > > |
|
|
Le 28/6/15 19:00, Sven Van Caekenberghe a écrit : >> On 28 Jun 2015, at 17:59, Max Leske <[hidden email]> wrote: >> >> >>> On 28 Jun 2015, at 17:22, stepharo <[hidden email]> 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. >> 2. The interface is pretty similar No there are not :) Stack is push pop top not insert after:..... or this is a strange stack. > 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. > >>> Stef >>> >> > > |
|
|
> On 30 Jun 2015, at 11:00, stepharo <[hidden email]> wrote: > > > > Le 28/6/15 19:00, Sven Van Caekenberghe a écrit : >>> On 28 Jun 2015, at 17:59, Max Leske <[hidden email]> wrote: >>> >>> >>>> On 28 Jun 2015, at 17:22, stepharo <[hidden email]> 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 >>>> >>> >> >> > > |
|
|
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 <[hidden email]> escribió:
|
|
|
We should really rename it to “ProcessList” and put a comment “do not touch!!!”, then make a copy and have a Linked List that we can change… there are many issue tracker entries related to the linked list, as people try to use it but nobody dares to change it. Marcus |
|
|
In reply to this post by stepharo
2015-06-30 11:00 GMT+02:00 stepharo <[hidden email]>:
Are you sure you mean that? *confused* Thierry |
|
|
What he means is that just because subclassing is available as a technical mechanism, we should only use it for modeling subtyping and not implementation reuse (only in very few cases this is actually useful in the long run). For reference, this goes under the name of Liskov substitution principle and one nice article that explains it is this one: Cheers, Doru On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier <[hidden email]> wrote:
|
|
|
2015-06-30 11:30 GMT+02:00 Tudor Girba <[hidden email]>:
Given how Smalltalk defines types and subtyping, I consider that subclassing should be used for implementation reuse and not for subtyping. Any Smalltalk class hierarchy which has instance variables defined in the superclass does implementation sharing/reuse. Modeling is another consideration. (I still consider the meaning of Stef phrase confusing...)
This reference is too much into how that particular principle turns out in an ill-designed type and code sharing mechanism (C++) to be of much help ;) Thierry
|
|
|
In reply to this post by Marcus Denker-4
I will open an issue ^^
El mar., 30 de jun. de 2015 a la(s) 11:20 a. m., Marcus Denker <[hidden email]> escribió:
|
|
|
In reply to this post by Max Leske
:)
my question was to check if we can change it :) Le 30/6/15 11:10, Max Leske a écrit : >> On 30 Jun 2015, at 11:00, stepharo <[hidden email]> wrote: >> >> >> >> Le 28/6/15 19:00, Sven Van Caekenberghe a écrit : >>>> On 28 Jun 2015, at 17:59, Max Leske <[hidden email]> wrote: >>>> >>>> >>>>> On 28 Jun 2015, at 17:22, stepharo <[hidden email]> 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 >>>>> >>> >> > > |
|
Administrator
|
In reply to this post by Thierry Goubier
That is the GoF position and it makes a lot of sense to me. In fact, I think we Smalltalkers suffer from McLuhan's "people become their tools" syndrome in that, because the browser makes it easy to view inheritance trees, we confuse inheritance with subtyping, creating unnecessary coupling. This also adds to the "Smalltalk has no APIs" problem; when only subclasses are considered subtypes, one never has to define what is and is not the public API; protocols could help here, but have never really been fleshed out for this purpose and are a mess right now due to overloading with extension method duties.
Cheers,
Sean |
|
|
2015-06-30 14:05 GMT+02:00 Sean P. DeNigris <[hidden email]>: Thierry Goubier wrote I'll wonder what could be done with Traits about that. Traits may be better at establishing an API. Tools could do more to hide the extension thing; I still can't understand why, more than two years after I did it, all Pharo users are still writing their * a-long-package-name by hand. I would hate having to explain to Pharo beginners how to make a method an extension. (by the way, dropping a method on a package is a nice way to get a DNU in Nautilus on Pharo 4...) Thierry |
|
|
In reply to this post by Thierry Goubier
On Tue, Jun 30, 2015 at 5:21 PM, Thierry Goubier
<[hidden email]> wrote: > > > 2015-06-30 11:00 GMT+02:00 stepharo <[hidden email]>: >>> >>> >> >> What I mean is that this is not good to have subclassing when we can use >> subclassing. > > > Are you sure you mean that? *confused* > > Thierry Was it meant to be... "not good to have subclassing when we can use composition" ? cheers -ben |
|
|
2015-06-30 15:30 GMT+02:00 Ben Coman <[hidden email]>:
That sounds like it :) Thierry
|
Administrator
|
In reply to this post by Sean P. DeNigris
Definitely +1 to that. One of the things I really like about ENVY (as in VA Smalltalk) is the fact that applications/packages have formally modelled prerequisites and the in-image representation of a class also models the contribution of each extending application. (As opposed to "by convention") I'm not claiming ENVY is the be all to end all. It has room for improvement. But it does formally model this particular aspect quite well. |
|
|
In reply to this post by Marcus Denker-4
Le 30/6/15 11:20, Marcus Denker a
écrit :
I reimplemented it once. Now I was just consider Stack implementation.
|
|
|
In reply to this post by Tudor Girba-2
+1
Thierry we are talking API substituability here. Le 30/6/15 11:30, Tudor Girba a écrit :
|
|
|
In reply to this post by Thierry Goubier
alain fixed in place edit for string morph so we could even rename a
protocol simply by double clicking on it.
But this is another story Le 30/6/15 15:24, Thierry Goubier a
écrit :
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |