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

Re: [Pharo-dev] About abuse of inheritance

by Florin Mateoc

I also liked the debate, so before it closes I want to throw my 2 cents in: I don't think this is an issue about inheritance (vs composition), it is one about multiple inheritance or lack thereof. You may want your object to be an announcer of events, but almost always you will also want it to be something else as well. To me this suggests that Announcer should be a trait, not a class, so in a sense, indeed, you would "compose" your classes using it, but you would use trait composition instead of class composition. In VisualAge there is a huge hierarchy underneath AbtObservableObject. Sure, there are many classes that want to participate in an observable pattern, but you should not be forced to inherit from a particular class in order to do that, so that is just another related example that would have benefited from traits. Florin On 7/22/2013 7:40 AM, Tudor Girba wrote: > I love this debate, but given the energy it attracted, I now apologize to have fueled it. > > By reading the thread, I believe that everyone involved in the discussion is on the same page on 99.9% of the cases, > the only real difference being the case of the Announcer (and even there, the difference is more philosophical in nature). > > Would it be Ok to call it a day and move on? :) > > Cheers, > Doru > > > > > On Mon, Jul 22, 2013 at 1:05 PM, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > > On 21 July 2013 20:21, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> > >> > >> Interesting how many people in this list think that "Announcer subclass: > >> #TxEditor" provides special implementation of announcer named TxEditor? > >> > >> > >> Many > >> this is composition using inheritance and inheritance should not be used > >> like that. > >> > >> Announcer subclass: #GreedyAnnouncer > >> > >> Announcer subclass: #RemoteAnnouncer > > > > > > And if we prefer composition we should not implement such kind of hierarchy. > > We should implement GreadySubscriptionsRegistry, RemoteSubscriptionsRegistry > > or AsynchSubscriptionsRegistry and reuse existed Announcer. All subscribing > > and delivering logic implemented by subscription registry. Announcer is just > > simple delegator with convenient api to create Subscription instances: > > > > Announcer>>subscribe: anAnnouncementClass do: aValuable > > "Declare that when anAnnouncementClass is raised, aValuable is executed." > > ^ registry add: ( > > AnnouncementSubscription new > > announcer: self; > > announcementClass: anAnnouncementClass; > > valuable: aValuable) > > > > > > Announcer>>announce: anAnnouncement > > > > | announcement | > > announcement := anAnnouncement asAnnouncement. > > registry ifNotNil: [ > > registry deliver: announcement > > ]. > > ^ announcement > > > > All magic happens inside #add: and #deliver: methods of > > SubscriptionsRegistry. > > > > Also announcements framework provides very nice feature: you can have > > announcer as last argument of event handler selector (that's why > > AnnouncementSubscription contains reference to announcer instance): > > > > announcer on: MyEvent send: #handleAnnouncement:raisedBy: to: aSubscriber > > > > Without subclassing YourEventsSource from Announcer you will not have such > > feature. Or you will need implement complex subscription method inside > > YourEventSource which will delegates special event handler to its announcer > > > > 1. you don't need separate class to represent event source. > it can be any object which does: > > announcer announce: Foo. > > in any place.. > I do not see any practical gains from forming a separate class for this role. > It is barely formalizeable because the way how users creating and > triggering events is arbitrary. > > 2. SubscriptionRegistry is an implementation detail. It is private. It > is a way how Announcer > doing things inside. It should be no concern of anything outside to > consider what it does. > You won't find this class in VisualWorks implementation, for instance. > > 3. again, event source - is any object which says 'announcer announce: ...' > It is NOT announcer, because announcer is an event dispatcher. > dispatcher ~= source > Is it so hard to see a difference? > > When you subclass from Announcer, is that you want to say: > > 'self announce:' , so the very same object acts both as event source > and event dispatcher. > > But then , as Stef said, by subclassing you inheriting API. > So, what prevents me from writing following code, in my own class, > which uses your domain object > in a following way: > > coolDomainObject := YourDomainObjectWhichInheritsFromAnnouncer new. > > coolDomainObject on: Foo do: #bar. > coolDomainObject announce: Foo. > > That i guess is not something you expected, huh? But why not? > As long as your object understand this protocol, and as long as you > don't overriding original behavior of Announcer, > i can abuse your object in a way you did not expected. > And this is a consequence of violating principle of least authority. > > Because once you declare that we're free to use subclassing for any purpose, > then, i can declare: i am free to use any subclass of Announcer as > announcer for myself. > > Lets write random code, do not follow any rules and everyone will be happy. > > --- > Best regards, > Igor Stasenko. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

July 22, 2013

[update 3.0] #30291

by Marcus Denker

30291 ----- 4533 UIThemeWatery and UIThemeWatery2 should be merged... https://pharo.fogbugz.com/f/cases/4533 11207 clean up some dead code in FileContentsBrowser https://pharo.fogbugz.com/f/cases/11207 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1189.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke…

July 22, 2013

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

by Tudor Girba

Wow! Doru On Mon, Jul 22, 2013 at 12:53 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Note this change improved a lot the loading time of Monticello > packages in general. > > The bench showed 3x speed-up loading Pier3 (from more than 10 minutes > to less than 4 minutes!) > > Thanks Esteban! > > MartÃn > > > On Mon, Jul 22, 2013 at 9:42 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > 30290 > > ----- > > > > 10393 Add RPackageSet cache > > https://pharo.fogbugz.com/f/cases/10393 > > > > > > Diff information: > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Core-MarcusDenker.24… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-MarcusDenker.839.d… > > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-Platform.pharo20-Ma… > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

July 22, 2013

Re: [Pharo-dev] [NB]: Review & fixes & ideas

by Henrik Johansen

On Jul 13, 2013, at 7:23 , Igor Stasenko wrote: > On 13 July 2013 14:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> what are the pros and cons? >> > pros - you can pass is as parameter everywhere it expects a pointer > cons - it will slow down all calls with pointer type because of extra check, > even if you don't using it (and in most cases you don't) > > i think best way is to introduce it as option. I think there's an -optNoChecks or something already? IMHO, it's would be nice to basically treat them as asserts; leave them on by default, then have a system-wide switch in case you want to disable them for production and gain some performance at the risk of crashes rather than failures in case of running into untested incorrect usage. (Optionally with an added -optForceChecks in case you write code that depends on an error being thrown for incorrectly passed typesâ¦ though that shouldn't really happen) Cheers, Henry PS: Sadly, summer in Norway has seen the best weather in ages :D

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Tudor Girba

I love this debate, but given the energy it attracted, I now apologize to have fueled it. By reading the thread, I believe that everyone involved in the discussion is on the same page on 99.9% of the cases, the only real difference being the case of the Announcer (and even there, the difference is more philosophical in nature). Would it be Ok to call it a day and move on? :) Cheers, Doru On Mon, Jul 22, 2013 at 1:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 July 2013 20:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> > >> Interesting how many people in this list think that "Announcer subclass: > >> #TxEditor" provides special implementation of announcer named TxEditor? > >> > >> > >> Many > >> this is composition using inheritance and inheritance should not be used > >> like that. > >> > >> Announcer subclass: #GreedyAnnouncer > >> > >> Announcer subclass: #RemoteAnnouncer > > > > > > And if we prefer composition we should not implement such kind of > hierarchy. > > We should implement GreadySubscriptionsRegistry, > RemoteSubscriptionsRegistry > > or AsynchSubscriptionsRegistry and reuse existed Announcer. All > subscribing > > and delivering logic implemented by subscription registry. Announcer is > just > > simple delegator with convenient api to create Subscription instances: > > > > Announcer>>subscribe: anAnnouncementClass do: aValuable > > "Declare that when anAnnouncementClass is raised, aValuable is executed." > > ^ registry add: ( > > AnnouncementSubscription new > > announcer: self; > > announcementClass: anAnnouncementClass; > > valuable: aValuable) > > > > > > Announcer>>announce: anAnnouncement > > > > | announcement | > > announcement := anAnnouncement asAnnouncement. > > registry ifNotNil: [ > > registry deliver: announcement > > ]. > > ^ announcement > > > > All magic happens inside #add: and #deliver: methods of > > SubscriptionsRegistry. > > > > Also announcements framework provides very nice feature: you can have > > announcer as last argument of event handler selector (that's why > > AnnouncementSubscription contains reference to announcer instance): > > > > announcer on: MyEvent send: #handleAnnouncement:raisedBy: to: aSubscriber > > > > Without subclassing YourEventsSource from Announcer you will not have > such > > feature. Or you will need implement complex subscription method inside > > YourEventSource which will delegates special event handler to its > announcer > > > > 1. you don't need separate class to represent event source. > it can be any object which does: > > announcer announce: Foo. > > in any place.. > I do not see any practical gains from forming a separate class for this > role. > It is barely formalizeable because the way how users creating and > triggering events is arbitrary. > > 2. SubscriptionRegistry is an implementation detail. It is private. It > is a way how Announcer > doing things inside. It should be no concern of anything outside to > consider what it does. > You won't find this class in VisualWorks implementation, for instance. > > 3. again, event source - is any object which says 'announcer announce: ...' > It is NOT announcer, because announcer is an event dispatcher. > dispatcher ~= source > Is it so hard to see a difference? > > When you subclass from Announcer, is that you want to say: > > 'self announce:' , so the very same object acts both as event source > and event dispatcher. > > But then , as Stef said, by subclassing you inheriting API. > So, what prevents me from writing following code, in my own class, > which uses your domain object > in a following way: > > coolDomainObject := YourDomainObjectWhichInheritsFromAnnouncer new. > > coolDomainObject on: Foo do: #bar. > coolDomainObject announce: Foo. > > That i guess is not something you expected, huh? But why not? > As long as your object understand this protocol, and as long as you > don't overriding original behavior of Announcer, > i can abuse your object in a way you did not expected. > And this is a consequence of violating principle of least authority. > > Because once you declare that we're free to use subclassing for any > purpose, > then, i can declare: i am free to use any subclass of Announcer as > announcer for myself. > > Lets write random code, do not follow any rules and everyone will be happy. > > --- > Best regards, > Igor Stasenko. > > -- www.tudorgirba.com "Every thing has its own flow"

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Igor Stasenko

On 21 July 2013 20:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> Interesting how many people in this list think that "Announcer subclass: >> #TxEditor" provides special implementation of announcer named TxEditor? >> >> >> Many >> this is composition using inheritance and inheritance should not be used >> like that. >> >> Announcer subclass: #GreedyAnnouncer >> >> Announcer subclass: #RemoteAnnouncer > > > And if we prefer composition we should not implement such kind of hierarchy. > We should implement GreadySubscriptionsRegistry, RemoteSubscriptionsRegistry > or AsynchSubscriptionsRegistry and reuse existed Announcer. All subscribing > and delivering logic implemented by subscription registry. Announcer is just > simple delegator with convenient api to create Subscription instances: > > Announcer>>subscribe: anAnnouncementClass do: aValuable > "Declare that when anAnnouncementClass is raised, aValuable is executed." > ^ registry add: ( > AnnouncementSubscription new > announcer: self; > announcementClass: anAnnouncementClass; > valuable: aValuable) > > > Announcer>>announce: anAnnouncement > > | announcement | > announcement := anAnnouncement asAnnouncement. > registry ifNotNil: [ > registry deliver: announcement > ]. > ^ announcement > > All magic happens inside #add: and #deliver: methods of > SubscriptionsRegistry. > > Also announcements framework provides very nice feature: you can have > announcer as last argument of event handler selector (that's why > AnnouncementSubscription contains reference to announcer instance): > > announcer on: MyEvent send: #handleAnnouncement:raisedBy: to: aSubscriber > > Without subclassing YourEventsSource from Announcer you will not have such > feature. Or you will need implement complex subscription method inside > YourEventSource which will delegates special event handler to its announcer > 1. you don't need separate class to represent event source. it can be any object which does: announcer announce: Foo. in any place.. I do not see any practical gains from forming a separate class for this role. It is barely formalizeable because the way how users creating and triggering events is arbitrary. 2. SubscriptionRegistry is an implementation detail. It is private. It is a way how Announcer doing things inside. It should be no concern of anything outside to consider what it does. You won't find this class in VisualWorks implementation, for instance. 3. again, event source - is any object which says 'announcer announce: ...' It is NOT announcer, because announcer is an event dispatcher. dispatcher ~= source Is it so hard to see a difference? When you subclass from Announcer, is that you want to say: 'self announce:' , so the very same object acts both as event source and event dispatcher. But then , as Stef said, by subclassing you inheriting API. So, what prevents me from writing following code, in my own class, which uses your domain object in a following way: coolDomainObject := YourDomainObjectWhichInheritsFromAnnouncer new. coolDomainObject on: Foo do: #bar. coolDomainObject announce: Foo. That i guess is not something you expected, huh? But why not? As long as your object understand this protocol, and as long as you don't overriding original behavior of Announcer, i can abuse your object in a way you did not expected. And this is a consequence of violating principle of least authority. Because once you declare that we're free to use subclassing for any purpose, then, i can declare: i am free to use any subclass of Announcer as announcer for myself. Lets write random code, do not follow any rules and everyone will be happy. --- Best regards, Igor Stasenko.

July 22, 2013

Nautilus running tests and expected failures

by Holger Hans Peter Freyther

Hi, I used Nautilus to browse some code and make myself familiar with a foriegn codebase. I inserted some code and pressed the button in the browser to execute the test. The button turned green, I got the test finished notification but my code was not executed. It took me a bit to figure out that this test is in the expected failure list and only by stepping through the exception handling and looking at the 'TestResult' returned from TestResult>>#runTest. Is there any color (not equal to green) that could be used to indicate expected failures? kind regards holger

July 22, 2013

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

by Martin Dias

Note this change improved a lot the loading time of Monticello packages in general. The bench showed 3x speed-up loading Pier3 (from more than 10 minutes to less than 4 minutes!) Thanks Esteban! MartÃn On Mon, Jul 22, 2013 at 9:42 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30290 > ----- > > 10393 Add RPackageSet cache > https://pharo.fogbugz.com/f/cases/10393 > > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/RPackage-Core-MarcusDenker.24… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-MarcusDenker.839.d… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Metacello-Platform.pharo20-Ma… > >

July 22, 2013

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

by Martin Dias

On Sat, Jul 20, 2013 at 8:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > On Fri, Jul 19, 2013 at 2:27 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> 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 > > > How does this work? Do you have an example at hand? Ben showed me how to sync a side bar morph with the scroll bar of a spec widget. We added a new announcement for listening scroll changes, and we decided to publish an example. You can see: ScrollSyncExample new openWithSpec Martin > > Doru > > > >> >> >> >> >> 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.… >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

2013/7/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > This is not because we have a dynamically typed language that we should > not use subtyping. > Have a look at my lecture there are slides on subtyping. > > Compare: > > OrderedCollection subclass: #Poem > of course a poem is a collection of word. Now it is not a subtype of > collection!!! > OrderedCollection subclass: #UniqueOrderedCollection > > > or compare > > OrderedCollection subclass: #Stack > > vs. > > Stack subclass: #HanoiStack > > Think in terms of API and polymorphic objects > I agree with your examples. And I never build my domain "container like classes" as subclass of OrderedCollection (or friends). But Announcer to me is different concern. It is like subclassing Object as Tudor said. What is all api of Announcer? > > Announcer allSelectors > It should be "Announcer selectors" (it is 16 methods). And I think it is wrong to name all methods of class as API. And I think Announcer API can be reduced to just 5 methods: #announce:, #on:do, #subscribe:send:to:, #unsubscribe:and #week. All others are private or just convenient aliases (maybe already deprecated). And this 5 methods is exactly what I need to subscribe on "event service" with enough flexibility. So when I implement my domain "event source" I need superclass which will supply to my service such nice API. And now there is only Announcer class for this. I were look at Announcer hierarchy. What do you think about SystemAnnouncer class? It has strange implementation. It is subclass of Announcer and it has another announcer instance named "private".

July 22, 2013