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

Fogbugz update

by Benjamin

Hi guys, just an email to announce that I changed the link pointed by the pharo logo in fogbugz. It used to point to an odd page which nobody uses (https://pharo.fogbugz.com/default.asp?pg=pgOldMainMenu) As Damien Pollet suggested, now it points to the Pharo Welcome page (https://pharo.fogbugz.com/default.asp?W46) Thanks, Ben

July 20, 2013

Re: [Pharo-dev] About abuse of inheritance

by H. Hirzel

On 7/19/13, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. not generally I assume Tudor thinks, only for this particular case of sub classing Announcer. Announcing behaviour may be considered part of a package objects should have and this has been the case in Smalltalk since the beginning, though implemented with the symbol based changed/update mechanism. To restate Yes, I agree that subclasses should specialize the behaviour of the superclass. But there need to be classes first you may subclass to specialize and these inherit general properties of object behaviour. --Hannes > 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 20, 2013

Re: [Pharo-dev] About abuse of inheritance

by Camillo Bruni

How about statefull Traits? http://scg.unibe.ch/archive/papers/Berg07aStatefulTraits.pdf On 2013-07-20, at 12:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi > > 2013/7/19 Igor Stasenko <siguctua(a)gmail.com> > >> 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' >> >> > ObjectWithAnnouncer is exactly what I think about Announcer. I just need > class which makes my objects events sources. And I'm wondering why > Announcer is bad for this? > Just look at Announcer definition: > > Object subclass: #Announcer > > instanceVariableNames: 'registry' > > classVariableNames: '' > > poolDictionaries: '' > > category: 'Announcements-Core' > > > "registry" variable is instance of SubscriptionsRegistry which actually > implements all announcements logic. Announcer just adds convenient public > api to events subscriptions and delivering. No complex logic. No actual > knowledge about how announcements work. > And your argument "why you subclass from Announcer" looks to me like why > you subclass from SubscriptionsRegistry. But I'm not. Nobody doing it. > So i'm not understand why you want another wrapper around Announcer. > > (To me "subscriptions" is better name then "registry". And I prefer > composition than inheritance too). > > > >> 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 20, 2013

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

Hi 2013/7/19 Igor Stasenko <siguctua(a)gmail.com> > 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' > > ObjectWithAnnouncer is exactly what I think about Announcer. I just need class which makes my objects events sources. And I'm wondering why Announcer is bad for this? Just look at Announcer definition: Object subclass: #Announcer instanceVariableNames: 'registry' classVariableNames: '' poolDictionaries: '' category: 'Announcements-Core' "registry" variable is instance of SubscriptionsRegistry which actually implements all announcements logic. Announcer just adds convenient public api to events subscriptions and delivering. No complex logic. No actual knowledge about how announcements work. And your argument "why you subclass from Announcer" looks to me like why you subclass from SubscriptionsRegistry. But I'm not. Nobody doing it. So i'm not understand why you want another wrapper around Announcer. (To me "subscriptions" is better name then "registry". And I prefer composition than inheritance too). > 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 20, 2013

Re: [Pharo-dev] Spec update

by StÃ©phane Ducasse

On Jul 19, 2013, at 7:16 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Hi guys :) > > Spec just got updated in 3.0 and the old TreeModel is now deprecated :) Yepee!!!! > 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 20, 2013

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

by Marcus Denker

On Jul 19, 2013, at 5:10 PM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > 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 > Can you add a bug tracker entry? Marcus

July 20, 2013

[update 3.0] #30286

by Marcus Denker

30286 ----- 11188 Be able to set an initial Filter in ListDialogWindow https://pharo.fogbugz.com/f/cases/11188 11196 Drag not working on AlainTreeModel https://pharo.fogbugz.com/f/cases/11196 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.213… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke…

July 20, 2013

Re: [Pharo-dev] [update 3.0] #30285

by StÃ©phane Ducasse

> 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 Thanks thanks thanks for all these improvements on Morphic.

July 20, 2013

Re: [Pharo-dev] Pharo3: all green (mostly)

by StÃ©phane Ducasse

> > Pharo3 build is green on mac and linux: > > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/ This is really nice achievement. I deeply appreciate it. Stef

July 20, 2013

Re: [Pharo-dev] [update 3.0] #30282

by StÃ©phane Ducasse

+1 On Jul 18, 2013, at 5:36 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > any years. I'm very happy Sebastian > worked on it. Thank you Sebast

July 20, 2013