Stack
Locked
12
12
 
|
>>> 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. > > |
|
|
In reply to this post by Ben Coman
Le 30/6/15 15:30, Ben Coman a écrit : > 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" ? 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 > > |
|
|
In reply to this post by stepharo
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 >> <[hidden email] <mailto:[hidden email]>> wrote: >> >> >> >> 2015-06-30 11:00 GMT+02:00 stepharo <[hidden email] >> <mailto:[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 >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" > |
|
|
In reply to this post by stepharo
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).=== 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 <[hidden email]> wrote:
-- Best regards,
Igor Stasenko. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |