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

Re: [Pharo-dev] [2.0] One Issue left!

by Marcus Denker

On Jul 22, 2013, at 10:06 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > https://pharo.fogbugz.com/default.asp?10234#76081 > https://github.com/pharo-project/pharo-core/releases/tag/30088 > > and the diff > https://github.com/pharo-project/pharo-core/commit/f797f401aa4c50db5cc30b91… > > and I think it is the first change on the Morph.cls itself > Thanks! I have submitted a fix. Marcus

July 22, 2013

Re: [Pharo-dev] [2.0] One Issue left!

by Camillo Bruni

https://pharo.fogbugz.com/default.asp?10234#76081 https://github.com/pharo-project/pharo-core/releases/tag/30088 and the diff https://github.com/pharo-project/pharo-core/commit/f797f401aa4c50db5cc30b91… and I think it is the first change on the Morph.cls itself On 2013-07-22, at 09:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > After checken/recategorizing, there is just one issue left to be evaluated for back porting > to 2.0: > > 10860 option click on list in TestRunner and others: freeze system > https://pharo.fogbugz.com/f/cases/10860 > > I know that this was fixed in Pharo3 already, but i can't find the issueâ¦ > > Marcus

July 22, 2013

[2.0] One Issue left!

by Marcus Denker

Hi, After checken/recategorizing, there is just one issue left to be evaluated for back porting to 2.0: 10860 option click on list in TestRunner and others: freeze system https://pharo.fogbugz.com/f/cases/10860 I know that this was fixed in Pharo3 already, but i can't find the issueâ¦ Marcus

July 22, 2013

[update 3.0] #30290

by Marcus Denker

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] About abuse of inheritance

by StÃ©phane Ducasse

On Jul 21, 2013, at 9:27 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > And what I should do if I want Customer which can trigger events? > > then ask yourself about the API of your customer > Do you want the full API of Announcer? I doubt. > > > Do you think "EventSource subclass: #Customer" make any difference? Or do you think we should never use inheritance to make domain announcer classes? What the existed alternative? I don't want always add announcer instance and couple equal methods any time I need it. > > Think about API not about code reuse. > Think about polymorphic objects. > Each time you subclass from Announcer ALL the API should make sense. > > What is all api of Announcer? Announcer allSelectors > It is just two methods: #announce: and #on:send:to:. No!! this is exactly my point. When you inherit from a class you get its API merged into the one of your class. > When I need "object with events" I always need this methods. What problem? We should not use subclassing for code reuse but use subclassing for subtyping (= polymorphic interface). 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 Stef

July 22, 2013

[update 3.0] #30289

by Marcus Denker

30289 ----- 11204 Crash if changes file is not writable https://pharo.fogbugz.com/f/cases/11204 11198 Update Pharo with latest Opal https://pharo.fogbugz.com/f/cases/11198 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke…

July 22, 2013

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > And what I should do if I want Customer which can trigger events? > > then ask yourself about the API of your customer > Do you want the full API of Announcer? I doubt. > > > Do you think "EventSource subclass: #Customer" make any difference? Or > do you think we should never use inheritance to make domain announcer > classes? What the existed alternative? I don't want always add announcer > instance and couple equal methods any time I need it. > > Think about API not about code reuse. > Think about polymorphic objects. > Each time you subclass from Announcer ALL the API should make sense. > What is all api of Announcer? It is just two methods: #announce: and #on:send:to:. When I need "object with events" I always need this methods. What problem?

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by StÃ©phane Ducasse

> And what I should do if I want Customer which can trigger events? then ask yourself about the API of your customer Do you want the full API of Announcer? I doubt. > Do you think "EventSource subclass: #Customer" make any difference? Or do you think we should never use inheritance to make domain announcer classes? What the existed alternative? I don't want always add announcer instance and couple equal methods any time I need it. Think about API not about code reuse. Think about polymorphic objects. Each time you subclass from Announcer ALL the API should make sense. We should use subclassing when you can potentially replace instance of the superclass by instance of the subclasses at least from the API point of you and that existing code calling the superclass still somehow work. > In practice in both cases my domain classes will never override methods from "events support superclass". > > And to me name "Announcer" is exactly events source. Is my english so bad here? Maybe we should rename it to "AnnouncerMediator" and real Announcer class? I like the distinction made by igor. I do not want to think in terms of Registry. I do not care in fact. I care that I have a class that can register and announce. > > Best regards, > Denis

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Nicolas Cellier

Of course, Dictionary was somehow a Set, but somehow behaved more like a Bag (it could be seen as a Bag of values w.r.t. #do: behavior),. But we still solved it with inheritance, just with an intermediate HashedCollection capturing common abstract behavior... 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jul 21, 2013, at 7:30 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Though, Dictionary was technically a Set of Associations, > > > yes but API(DICTIONARY) is not the same as API(SET) => ARGHHHHHHHHHHHHHHHHH > > until someone changed Association>>= to also compare values. > > > subclassing does not mean that technically it is wrong. subclassing is > reuse so reuse is happening > but at the cost of bending APIs and killing the poor maintainers with yyy > ^ super xxx and should not understand. > > Stef > > > > 2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> On Jul 21, 2013, at 5:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >> 2013/7/21 Igor Stasenko <siguctua(a)gmail.com> >> >>> Yes, but where are the guarantees that you don't? >>> Just think from outsider's point of view: when he sees >>> >>> Announcer subclass: #Foo >>> >>> what he will think first: >>> - aha, this guy implements own kind of announcer >>> or >>> - aha this guy reusing announcer >>> or >>> - aha, this guy doing both things at the same time (a worst possible >>> alternative) >>> >>> and how many abuses like that, he should see before making a logical >>> conclusion: >>> - aha.. this is the way how i should do as well. >>> >> >> 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 >> >> Are quite different from >> Announcer subclass: #Customer >> >> This is not because subclassing can be used that we should do it. >> We suffer during years from >> Dictionary subclass: #Set >> and other beauties. >> >> >> >> >> Because to me it is not practical design issues when we talk about >> subclassing Announcer. >> >> >> > >

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Denis Kudriashov

2013/7/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Announcer subclass: #Customer And what I should do if I want Customer which can trigger events? Do you think "EventSource subclass: #Customer" make any difference? Or do you think we should never use inheritance to make domain announcer classes? What the existed alternative? I don't want always add announcer instance and couple equal methods any time I need it. In practice in both cases my domain classes will never override methods from "events support superclass". And to me name "Announcer" is exactly events source. Is my english so bad here? Maybe we should rename it to "AnnouncerMediator" and real Announcer class? Best regards, Denis

July 21, 2013