Hi guys is there a real reason for Stack being a subclass of LinkedLink? Stef
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. 2. The interface is pretty similar
Stef
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. 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 <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. >> 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 <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 >>>> >>> >> >> > >
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 > >>>> > >>> > >> > >> > > > > > > >
On 30 Jun 2015, at 11:16, Guillermo Polito <guillermopolito@gmail.com> wrote:
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 ^^.
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
I will open an issue ^^ El mar., 30 de jun. de 2015 a la(s) 11:20 a. m., Marcus Denker < marcus.denker@inria.fr> escribió:
On 30 Jun 2015, at 11:16, Guillermo Polito <guillermopolito@gmail.com> wrote:
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 ^^.
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
Le 30/6/15 11:20, Marcus Denker a écrit :
On 30 Jun 2015, at 11:16, Guillermo Polito <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>> wrote:
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 ^^.
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.
I reimplemented it once. Now I was just consider Stack implementation.
Marcus
:) 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 <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 >>>>> >>> >> > >
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: http://www.objectmentor.com/resources/articles/lsp.pdf Cheers, Doru On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
2015-06-30 11:00 GMT+02:00 stepharo <stepharo@free.fr>:
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
-- www.tudorgirba.com "Every thing has its own flow"
2015-06-30 11:30 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
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).
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...)
For reference, this goes under the name of Liskov substitution principle and one nice article that explains it is this one: http://www.objectmentor.com/resources/articles/lsp.pdf
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
Cheers, Doru
On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2015-06-30 11:00 GMT+02:00 stepharo <stepharo@free.fr>:
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
-- www.tudorgirba.com
"Every thing has its own flow"
Thierry Goubier wrote
I consider that subclassing should be used for implementation reuse and not for subtyping.
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 -- View this message in context: http://forum.world.st/Stack-tp4834494p4834869.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2015-06-30 14:05 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:
Thierry Goubier wrote
I consider that subclassing should be used for implementation reuse and not for subtyping.
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.
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
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 :
2015-06-30 14:05 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:
Thierry Goubier wrote > I consider that subclassing should be used for implementation reuse and > not for subtyping.
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.
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
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. But maybe like that it makes some tools look better. Thierry
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
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.
Sean P. DeNigris wrote
Thierry Goubier wrote
I consider that subclassing should be used for implementation reuse and not for subtyping. 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.
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. -- View this message in context: http://forum.world.st/Stack-tp4834494p4834964.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I consider that subclassing should be used for implementation reuse and not for subtyping. 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.
+ 10
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 worked with Envy too and to me this is close to the package we have. And soon we will have package level dependencies.
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.
-- View this message in context: http://forum.world.st/Stack-tp4834494p4834964.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
+1 Thierry we are talking API substituability here. Le 30/6/15 11:30, Tudor Girba a écrit :
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: http://www.objectmentor.com/resources/articles/lsp.pdf
Cheers, Doru
On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-06-30 11:00 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
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
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Le 30/06/2015 19:26, stepharo a écrit :
+1
Thierry we are talking API substituability here.
Yes I know. Thierry
Le 30/6/15 11:30, Tudor Girba a écrit :
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: http://www.objectmentor.com/resources/articles/lsp.pdf
Cheers, Doru
On Tue, Jun 30, 2015 at 11:21 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-06-30 11:00 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
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
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
On Tue, Jun 30, 2015 at 5:21 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-06-30 11:00 GMT+02:00 stepharo <stepharo@free.fr>:
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 <btc@openinworld.com>:
On Tue, Jun 30, 2015 at 5:21 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-06-30 11:00 GMT+02:00 stepharo <stepharo@free.fr>:
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" ?
That sounds like it :) Thierry
cheers -ben
Le 30/6/15 15:30, Ben Coman a écrit :
On Tue, Jun 30, 2015 at 5:21 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-06-30 11:00 GMT+02:00 stepharo <stepharo@free.fr>:
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" ?
and produce coherent API. A stack is not a LinkedList. He can be implemented using a linkedlist. The API of a stack is not the one of a linkedlist.
cheers -ben
participants (11)
-
Ben Coman -
Guillermo Polito -
Igor Stasenko -
Marcus Denker -
Max Leske -
Richard Sargent -
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba