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

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

[update 3.0] #30284

by Marcus Denker

July 19, 2013

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

by Sven Van Caekenberghe

On 19 Jul 2013, at 09:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Pharo3 build is green on mac and linux: > > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/ Super ! > On win we have some strange test failures (just on the build server, I think) > > - Zinc.Tests.ZnServerTests.testEntityTooLarge > - Zinc.Tests.ZnServerTests.testHeaderLineTooLong > - Zinc.Tests.ZnServerTests.testRequestLineTooLong > > The issue for this is here: > > https://pharo.fogbugz.com/f/cases/10908 Sadly, the failures occur not only on the build server. I will comment in the issue. Sven

July 19, 2013

[Issue Tracker] Progress...

by Marcus Denker

Hi, Status of the issue tracker: - Overall open issues: 486 out of those, some are tagged for a Milestone. (this means "has to be fixed before a release is possible"): - Pharo2: 2 - Pharo3: 87 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. Marcus

July 19, 2013

Pharo3: all green (mostly)

by Marcus Denker

Hi, Pharo3 build is green on mac and linux: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/ On win we have some strange test failures (just on the build server, I think) - Zinc.Tests.ZnServerTests.testEntityTooLarge - Zinc.Tests.ZnServerTests.testHeaderLineTooLong - Zinc.Tests.ZnServerTests.testRequestLineTooLong The issue for this is here: https://pharo.fogbugz.com/f/cases/10908

July 19, 2013