- Pharo-dev - lists.pharo.org

[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

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