July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About abuse of inheritance

by Max Leske

Great answer Igor! I'm curious about Doru's response :) On 19.07.2013, at 17:31, Igor Stasenko <siguctua(a)gmail.com> wrote: > So, on your place, if you really need a lot of classes with announcer > capabilities, you can do it like that: > > Object subclass: #ObjectWithAnnouncer > instvars: 'announcer' > > then may implement same protocol as in Announcer in it, which will > simply delegate to announcer ivar. > And i bet, you don't want to expose full Announcer protocol there, > while probably you may want to implement some convenience protocols, > which Announcer lacking. > > So, at the end by subclassing from ObjectWithAnnouncer you will be > reusing its capabilities in each and every subclass of it, but by > delegating real job, you are free from worrying about dealing with > implementation detail and exposing unwanted state/protocols to its > users. > > Another aspect of it, is when i see: > > ObjectWithAnnouncer subclass: #MyDomainObject > > it tells me, aha.. so some (at least this one) of his domain objects > having announcers, > and the valid protocols is defined in ObjectWithAnnouncer. > > but when i see > > Announcer subclass: #MyDomainObject > > i starting to be uncertain: is Announcer private there or public? > can i send messages like #basicSubscribe: to your domain object and expect that > it will be handled correctly? Or do i allowed to subscribe directly at > all, because maybe > domain object has some specific protocol(s) and ways to do that.. > Every such question and uncertainty for coder means more time, more > errors, and less productivity. > > > -- > Best regards, > Igor Stasenko. >

July 19, 2013

Re: [Pharo-dev] About abuse of inheritance

by Esteban A. Maringolo

When you inherit, being it for specification or implementation, you're signing a contract with all what superclasses implement. Sometimes it is worth the risk, other times it isn't. I'm in for composition over inheritance, but Smalltalk is so malleable I wouldn't implement any restriction. Otherwise you'll have to enforce something like interfaces. Regards, Esteban A. Maringolo

July 19, 2013

Spec update

by Benjamin

Hi guys :) Spec just got updated in 3.0 and the old TreeModel is now deprecated :) So the AlainTreeModel is now known as TreeModel, and TreeModel is now OldTreeModel (in Spec-Deprecated). The migration should be simple since both API are the same. Just think to change the name of the widget during the widgets initialisation (#initializeWidgets) Thank you :) Ben

July 19, 2013

Re: [Pharo-dev] About abuse of inheritance

by Paul Davidowitz

Igor - could you please explain 'the principle of least authority'? Thanks, - Paul

July 19, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

So, on your place, if you really need a lot of classes with announcer capabilities, you can do it like that: Object subclass: #ObjectWithAnnouncer instvars: 'announcer' then may implement same protocol as in Announcer in it, which will simply delegate to announcer ivar. And i bet, you don't want to expose full Announcer protocol there, while probably you may want to implement some convenience protocols, which Announcer lacking. So, at the end by subclassing from ObjectWithAnnouncer you will be reusing its capabilities in each and every subclass of it, but by delegating real job, you are free from worrying about dealing with implementation detail and exposing unwanted state/protocols to its users. Another aspect of it, is when i see: ObjectWithAnnouncer subclass: #MyDomainObject it tells me, aha.. so some (at least this one) of his domain objects having announcers, and the valid protocols is defined in ObjectWithAnnouncer. but when i see Announcer subclass: #MyDomainObject i starting to be uncertain: is Announcer private there or public? can i send messages like #basicSubscribe: to your domain object and expect that it will be handled correctly? Or do i allowed to subscribe directly at all, because maybe domain object has some specific protocol(s) and ways to do that.. Every such question and uncertainty for coder means more time, more errors, and less productivity. -- Best regards, Igor Stasenko.

July 19, 2013

Re: [Pharo-dev] opal bug with the old debugger

by Andrei Vasile Chis

Just noticed that the second bug also appears in the new debugger. To reproduce execute (with either debugger) while debugging add a message send to a method that does not exist, step into that message send and then choose to create the method. After you created you'll get: UndefinedObject(Object)>> doesNotUnderstand: #debugHighlightRange Andrei On Mon, Jul 15, 2013 at 9:37 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Hi, > > Actually I saw the bug, tried in the new debugger, it worked. So I didn't > fix it because the new debugger will be integrated before the release. > > > 2013/7/14 Andrei Vasile Chis <chisvasileandrei(a)gmail.com> > >> Hi, >> >> Executing '1 haba' in a workspace and then choosing create method from >> the pre debug window leads to this >> exception: UndefinedObject(Object)>>doesNotUnderstand: #methodOrBlockNode >> >> If instead I choose to debug, select the top context of the stack and the >> press the 'Creare method' button a different exception is >> thrown: UndefinedObject(Object)>>doesNotUnderstand: #debugHighlightRange >> >> In both cases the method is created. >> >> So known or unknown issue? >> Also it doesn't seem to happen with the new debugger. Not sure why :) >> >> Andrei >> > >

July 19, 2013

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