- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

On 19 July 2013 16:17, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > I love these discussions. I agree that abusing inheritance is > counter-productive. Definitely, "Shampoo subclass: #Shower" does not match > any mental model I can think of. But, I am not seeing "Announcer subclass: > #MyDomainConcept" equally as an abuse. > > Here is why. > > When I say "Object subclass: #MyDomainConcept", my actual intention is not > to reuse types necessarily, but rather the infrastructure needed for the > Smalltalk runtime. From this point of view, it is an implementation > inheritance. I could as well, inherit from ProtoObject, but I do not do it > because Object gives me a bit more technical infrastructure. > > For me, Announcer is nothing but an Object that has an extra technical > capability. Inheriting from Announcer rather than Object seems the same as > inheriting from Object rather than ProtoObject. > > Now, you can shoot. > As i understood, you see nothing wrong in using inheritance as reuse, while i do. The argument with Object does not stands, to my thinking, because it is most generic class, and protocols it implements used by various parts of a system, including reflection etc, and those parts actually expecting that all objects they dealing with is at least implementing Object protocol(s). So, strictly speaking by inheriting from Object you may call it reuse, but to my thinking it is more about having a guarantee that your class will play well with the rest of smalltalk ecosystem (even if it's not your direct concern). While in case of inheriting from Announcer it is something different: you already have specific behavior which is non-universal for all objects in system (otherwise why not implementing Announcer protocol in Object?). Also, i am sure you aware, that by doing this, you introducing a certain degree of rigidness in your model (every time you refer directly to names instead of protocols, little kittie dies ;) because if today, Announcer serves well for your needs, and all is happy.. but maybe tomorrow, one guy will make a better one AnnouncerOnSteroids.. and to reuse it , you will need to change the parent in all numerous classes where you used Announcer originally. And to make it absolutely ridiculous, imagine how you will give user a choice whether use one Announcer or AnnouncerOnSteroids? You will recompile your classes each time? And what if parts of your model insist on using just Announcer while others having no problem with trying to play with AnnouncerOnSteroids? Another aspect of such abuse is when you inherit, you are tempted to use direct access to internal state and private methods, and that leads to really strange and complex problems later.. Just giving you an example: Suppose we have a class Butter, which implements #numberOfCalories and #fatPercentage protocols.. Now we do it like that: Butter subclass: #Fridge and then, of course fridge := Fridge new. fridge fatPercentage or: fridge fatPercentage: 10. ^^^ just look at the above line, how much sense you think this piece of code makes for reader, who will try to reason what is happens in your code? And why you think it is not the same story with Announcer? Because by subclassing from it, you expose its protocol(s) in places where it is not needed and will cause problems and confusion. Because when you inherit to reuse, not to specialize, then users of such class in most cases won't use full protocol of the superclass, nor require it.. and therefore by providing more than necessary, you are basically violating the principle of least authority. To fix that, you will need to override certain methods in your subclass to prevent exposing unwanted/low-level behavior to users. But that's again wrong, because then your model now starting to know too much about Announcer's internals, which should be an implementation detail, and adds even more rigidness to your design. -- Best regards, Igor Stasenko.

July 19, 2013

Re: [Pharo-dev] modeling Zinc request method

by Sven Van Caekenberghe

Doru, On 16 Jul 2013, at 22:24, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The recently announced cool tutorial on using Zinc made me read the Zinc code in a bit more detail. I must admit, it makes for a nice read. Thanks. > In the process, I stumbled across: > > knownHTTPMethods > ^ #( > "Standard HTTP 1.1 Verbs" > GET PUT POST DELETE HEAD > TRACE OPTIONS CONNECT PATCH > "WebDAV verbs" > PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK) > > I would propose to model these as classes (inheriting from ZnRequestMethod). > > If we would have such a hierarchy, then the following code: > > ZnSingleThreadedServer>>handleRequest: request > ... > request method = #HEAD > ifTrue: [ response clearEntity ]. > > > Could become something like: > > ZnSingleThreadedServer>>handleRequest: request > ... > request method clearEntityForSingleThreadedServerResponse: response > > ZnRequestMethod>>clearEntityForSingleThreadedServer: aResponse > "nothing" > > ZnHeadRequestMethod>>clearEntityForSingleThreadedServer: aResponse > aResponse clearEntity > > > What do you think? It is super exciting that you are willing to have a look at some of the Zinc internals and are giving feedback and suggestions. I know that some parts of Zinc could be improved quite a bit. For example, when I started in 2010, I tried to not write any extension methods anywhere. Hence there are some rather silly utility classes - that has to be changed. In other places, an even stronger object oriented approach (using full delegation, ask don't tell), could improve things. I absolutely like double dispatch, but sometimes I come across lots of methods on basic classes that are presumable used for double dispatch, but don't make sense on their own or for anyone else. I don't know, but somehow it feels to me as if that should be a criterium. Unless of course you consider an *extension as totally private. Now, for your specific suggestion, yes it could make sense. There are 4 places in the current code base where that would be useful: - ZnClient>>#executeRequestResponse - ZnClient>>#prepareRedirect - ZnClient>>#curl - ZnSingleThreadedServer>>#handleRequest: The other cases are related to HTTP dispatching or routing in delegates (objects implementing #handleRequest: like ZnStaticFileServerDelegate). In this last case the hierarchy could be useful too, but I am not 100% sure. You see, HTTP dispatching/routing is multi-dimensional: it is done on HTTP method, but also on the URL, query parameters or headers. I envision an additional generic dispatch for handling requests based on their method. Like this: MyApp>>handleRequest: request request method dispatchRequest: request on: self ZnGetRequestMethod>>dispatchRequest: request on: object object handleGetRequest: request ZnPutRequestMethod>>dispatchRequest: request on: object object handlePutRequest: request [..] MyApp>>handleGetRequest: request MyApp>>handlePutRequest: request The problem is that there are quite a lot method types, hence it would require the implementation of many #handleXXXRequest: methods on the target. This could be solved by inheritance, with empty implementations, but right now handlers do not have to subclass some specific class, and I like that. So the 'fanout' would be 'wide'. I don't think this can be solved with Traits either. Some trick with #respondsTo: or catching DNU could overcome this 'problem', but is a more of a hack. This idea of 'we will send some message to you if you implement it' is I believe quite common in Cocoa/Object-C for example. Do you understand what I mean ? What do you think ? Sven PS: I am going to take a short one week holiday and I am planning to keep my computer closed, so I am off the grid ;-) > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it cannot be done."

July 19, 2013

Re: [Pharo-dev] About abuse of inheritance

by Tudor Girba

Hi Igor, I love these discussions. I agree that abusing inheritance is counter-productive. Definitely, "Shampoo subclass: #Shower" does not match any mental model I can think of. But, I am not seeing "Announcer subclass: # MyDomainConcept" equally as an abuse. Here is why. When I say "Object subclass: #MyDomainConcept", my actual intention is not to reuse types necessarily, but rather the infrastructure needed for the Smalltalk runtime. From this point of view, it is an implementation inheritance. I could as well, inherit from ProtoObject, but I do not do it because Object gives me a bit more technical infrastructure. For me, Announcer is nothing but an Object that has an extra technical capability. Inheriting from Announcer rather than Object seems the same as inheriting from Object rather than ProtoObject. Now, you can shoot. Cheers, Doru On Fri, Jul 19, 2013 at 3:32 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > I just stumbled upon this: > > Announcer subclass: #TxEditor > .... > > This is just plain wrong, as wrong as: > > Shampoo subclass: #Shower > > because every time you treat inheritance as something else as > _specialization_ you doing it wrong. > Inheritance is not about importing needed functionality, it should be > about specialization and only about it: > - a superclass provides generic functionality, while subclasses > providing more and more specialized forms of it. > > Because if we don't follow that, then it is really hard to see and > follow a structure in design.. it is just random. > > And here's why: > > so since shower uses shampoo, as we concluded, then why not including > it via inheritance: > > Shampoo subclass: #Shower > > but then, Shower also uses Soap, so maybe it should be like that: > > Soap subclass: #Shower > > so, which superclass you prefer most? And how do you pick/prioritize > which element should be a superclass of Shower? > > To solve this dilemma, i think we will need multiple inheritance: > > (Shampoo, Soap) subclass: #Shower > > but thankfully, we don't have it in classic smalltalk model :) > > So, then maybe it should be something like that: > > Object subclass: #Shower > instanceVariableNames: 'soap shampoo' > ... > > Anyways, despite the obvious abuses, i'd like to ask community, in > what cases , you think (ab)using inheritance in a way > like above is justified? > Because maybe it is i, who doing it wrong? > > > -- > Best regards, > Igor Stasenko. > > -- www.tudorgirba.com "Every thing has its own flow"

July 19, 2013

Penelope update

by Benjamin

Hello :) Nicolas and I did a new pass on Penelope and finally fixed (we hope) the email address issue :) Moreover, there is now a permalink for registration: http://bugs.pharo.org/issues/register Ben

July 19, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

On 19 July 2013 15:48, Sebastian Tleye <stleye(a)gmail.com> wrote: > > > > 2013/7/19 Igor Stasenko <siguctua(a)gmail.com> >> >> I just stumbled upon this: >> >> Announcer subclass: #TxEditor >> .... >> >> This is just plain wrong, as wrong as: >> >> Shampoo subclass: #Shower >> >> because every time you treat inheritance as something else as >> _specialization_ you doing it wrong. >> Inheritance is not about importing needed functionality, it should be >> about specialization and only about it: > > > Completely agree! > If you inherit only because of reuse functionality, use traits instead :-) > Well, traits, i think, belong more to concern-oriented designs: when you wanna put handle concern in two (or more) different classes, which belong to different inheritance hierarchies. Else, this is just a poor-man's multiple inheritance. -- Best regards, Igor Stasenko.

July 19, 2013

Re: [Pharo-dev] About abuse of inheritance

by Sebastian Tleye

2013/7/19 Igor Stasenko <siguctua(a)gmail.com> > I just stumbled upon this: > > Announcer subclass: #TxEditor > .... > > This is just plain wrong, as wrong as: > > Shampoo subclass: #Shower > > because every time you treat inheritance as something else as > _specialization_ you doing it wrong. > Inheritance is not about importing needed functionality, it should be > about specialization and only about it: > Completely agree! If you inherit only because of reuse functionality, use traits instead :-) - a superclass provides generic functionality, while subclasses > providing more and more specialized forms of it. > > Because if we don't follow that, then it is really hard to see and > follow a structure in design.. it is just random. > > And here's why: > > so since shower uses shampoo, as we concluded, then why not including > it via inheritance: > > Shampoo subclass: #Shower > > but then, Shower also uses Soap, so maybe it should be like that: > > Soap subclass: #Shower > > so, which superclass you prefer most? And how do you pick/prioritize > which element should be a superclass of Shower? > > To solve this dilemma, i think we will need multiple inheritance: > > (Shampoo, Soap) subclass: #Shower > > but thankfully, we don't have it in classic smalltalk model :) > > So, then maybe it should be something like that: > > Object subclass: #Shower > instanceVariableNames: 'soap shampoo' > ... > > Anyways, despite the obvious abuses, i'd like to ask community, in > what cases , you think (ab)using inheritance in a way > like above is justified? > Because maybe it is i, who doing it wrong? > > > -- > Best regards, > Igor Stasenko. > >

July 19, 2013

About abuse of inheritance

by Igor Stasenko

I just stumbled upon this: Announcer subclass: #TxEditor .... This is just plain wrong, as wrong as: Shampoo subclass: #Shower because every time you treat inheritance as something else as _specialization_ you doing it wrong. Inheritance is not about importing needed functionality, it should be about specialization and only about it: - a superclass provides generic functionality, while subclasses providing more and more specialized forms of it. Because if we don't follow that, then it is really hard to see and follow a structure in design.. it is just random. And here's why: so since shower uses shampoo, as we concluded, then why not including it via inheritance: Shampoo subclass: #Shower but then, Shower also uses Soap, so maybe it should be like that: Soap subclass: #Shower so, which superclass you prefer most? And how do you pick/prioritize which element should be a superclass of Shower? To solve this dilemma, i think we will need multiple inheritance: (Shampoo, Soap) subclass: #Shower but thankfully, we don't have it in classic smalltalk model :) So, then maybe it should be something like that: Object subclass: #Shower instanceVariableNames: 'soap shampoo' ... Anyways, despite the obvious abuses, i'd like to ask community, in what cases , you think (ab)using inheritance in a way like above is justified? Because maybe it is i, who doing it wrong? -- Best regards, Igor Stasenko.

July 19, 2013

Re: [Pharo-dev] [Issue Tracker] Progress...

by Marcus Denker

On Jul 19, 2013, at 3:08 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> The issues tagged Pharo3 are not all real showstoppers, we should >> check each and remove the release tag from the ones that are not >> important. > > Now that we are on a calendar release, does it make sense to do it this > early in the year? In my experience, anything not tagged for the current > release gets totally ignored (even by the monkey ;)). For me, there's a wide > spectrum between showstopper and unimportant. I understand and agree with > the idea, but for me it would make more sense when we go to beta or > feature-freeze or whatever we call it. > The problem is that right now we don't know what is important and what not. When a list of things to do reaches >35, people just give up and don't look anymore. "Why do anything, even if I fix 2 it's of no value compared to the overall task". So limiting us artificially magically makes people feel that even fix 1 issue has an impact. Marcus

July 19, 2013

Re: [Pharo-dev] [Issue Tracker] Progress...

by Sean P. DeNigris

Marcus Denker-4 wrote > The issues tagged Pharo3 are not all real showstoppers, we should > check each and remove the release tag from the ones that are not > important. Now that we are on a calendar release, does it make sense to do it this early in the year? In my experience, anything not tagged for the current release gets totally ignored (even by the monkey ;)). For me, there's a wide spectrum between showstopper and unimportant. I understand and agree with the idea, but for me it would make more sense when we go to beta or feature-freeze or whatever we call it. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Issue-Tracker-Progress-tp4699488p4699586.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 19, 2013

[update 3.0] #30285

by Marcus Denker

30285 ----- 10823 Kill old list model https://pharo.fogbugz.com/f/cases/10823 11136 RadioButtonGroupExample new openWithSpec is not working https://pharo.fogbugz.com/f/cases/11136 11174 Add support for sync position of multiple widgets with just one scroll bar https://pharo.fogbugz.com/f/cases/11174 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Examples-MarcusDenker.33… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.48.…

July 19, 2013