- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Killing respondsTo:

by Tudor Girba

+1 Doru On May 14, 2013, at 10:27 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > why do we want to introduce a bad slow type system on certain single place? > Why a UI element would have to check that a given instance can do something > while we never ever do it in any other places. > > if we have a button and its label should be able to answer the message enabled > then we display the button and send the message enabled. > If it crashes then this is the programmer' fault. He should provide an object that responds > to enabled but we do not test it. > > And we should have nice polymorphic objects and not string and nil and color > why not array with hexa decimal colors? > > Being reasonable programmers and not kids wanted to plug anything anyhow > is the way to build nice system (and polymorphic objects). > > Stef > >> On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> I'm in favor killing all the respondsTo: >>> >>> acceptTextMorphs >>> "Accept any text morphs except for those that have no edits." >>> >>> self allMorphs do: [:p | >>> ((p respondsTo: #accept) and: [ >>> (p respondsTo: #hasUnacceptedEdits) and: [ >>> p hasUnacceptedEdits]]) ifTrue: [p accept]] >> >> They're a step up from #isKindOf:. It looks like you need is something >> that says "does this object respond to a particular set of messages >> (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! >> :) ) >> >> But in this particular case the solution looks like making a >> #insertADecentNameHere that particular classes of things can implement >> as "^ self hasUnacceptedEdits ifTrue: [self accept]" >> >> frank >> > > -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by stephane ducasse

On May 14, 2013, at 7:05 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > One of the most innovative concepts Smalltalk brought as a language in > the 1970's is the notion of sending messages. I don't think removing > #respondsTo: will help cure bad code. It will It is like isKindOf: Signs of non polymorphic code and/or unexpected contracts. > For a system as capable as > Pharo, to go far with it, I just don't think there's any way around > the need for students to /learn/ the best practices and not use > unnecessary reflection in apps. But /app-building/ frameworks often > need to be able to reflect on the code model. wellâ¦ It is a sign of non polymorphic design. And in the industrial systems we are building we do not want that too. > On Tue, May 14, 2013 at 10:21 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> I'm in favor killing all the respondsTo: >> >> acceptTextMorphs >> "Accept any text morphs except for those that have no edits." >> >> self allMorphs do: [:p | >> ((p respondsTo: #accept) and: [ >> (p respondsTo: #hasUnacceptedEdits) and: [ >> p hasUnacceptedEdits]]) ifTrue: [p accept]] >> >> :) >> >> And there are too many Smalltalk references in the system >> >

May 14, 2013

Re: [Pharo-dev] vm fixes

by Tudor Girba

This sounds intriguing. Can you be more specific? :) Doru On May 14, 2013, at 10:23 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Thank you :) > > This fix goes with pair with > https://pharo.fogbugz.com/default.asp?10619 > > Thanks to Esteban, one can now deploy a Spec widget with the os window as window :) > > Ben > > On May 14, 2013, at 10:19 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> thanks esteban! >> >> On May 14, 2013, at 9:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> Hi, >>> >>> I just pushed fix for a weird bug in cocoa cog vm. >>> It was crashing image when resizing using DisplayScreen>>#hostWindowSize: but even worst, some times was crashing also when dragging a window outside the world screen... >>> >>> The fix is there, but you will need to wait until tomorrow to have it in zeroconf (because of weird mac jenkins slave permissions). >>> >>> This increases a bit more the VM stability, still not perfect, but we are getting closer :) >>> >>> Esteban >> >> > -- www.tudorgirba.com "Presenting is storytelling."

May 14, 2013

Re: [Pharo-dev] about theme and friends

by Tudor Girba

Hi, On May 14, 2013, at 10:18 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> Hi, >> >> I was rather thinking of having the theme be a composable factory: >> - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory. > > Why a factory and not just the morph? Because you will need a place that will orchestrate how multiple morphs look. Of course, some of the properties can become part of the morph, but you will still need the theme responsible object. >> - the UITheme simply stores all these factories, and the morph looks the factory up via the theme. > > I do not get it. > One key question is do we want to have the theme removable or not. > Now if we would pushed only data through the hooks of the widgets it could work > but we will have to be able to specify specific computation for a given widgets and theme. > So may be this is what you mean by factory but this is still not clear to me. I am not sure what you mean by removable, but I think we should be able to remove a particular theme, but not the theme as a concept. >> - the UITheme will have no more subclasses. > > But you will have multiple subclasses of each of the factories? Yes. >> - in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme. >> >> This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside. > > Yes but the GroupBoxFactory will also be out of the GroupBoxMorph so this is not clear to me how this is different GroupBoxMorph>>doSomething self theme groupBoxFactory doSomethingWith: self The two will work together tightly. The advantage is that you will not have all drawing methods in one class, but nicely separated into dedicated classes. And then I can do: UITheme current textFactory: StandardTextFactory new; groupBoxFactory: FancyGroupBoxFactory new; ... Cheers, Doru >> >> Cheers, >> Doru >> >> >> >> On May 14, 2013, at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Looking at the code I have the impression that many UITheme methods should be moved to the their classes >>> >>> Example: >>> >>> >>> UITheme>>newGroupboxIn: aThemedMorph label: aString >>> "Answer a groupbox with the given label." >>> >>> ^GroupboxMorph new >>> font: self labelFont; >>> cornerStyle: aThemedMorph preferredCornerStyle; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill; >>> label: aString; >>> yourself >>> >>> Why this is not a creation method on GroupBox? >>> >>> Then the trait TeasilyThemed looks suspicious to me. >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> > > -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by stephane ducasse

why do we want to introduce a bad slow type system on certain single place? Why a UI element would have to check that a given instance can do something while we never ever do it in any other places. if we have a button and its label should be able to answer the message enabled then we display the button and send the message enabled. If it crashes then this is the programmer' fault. He should provide an object that responds to enabled but we do not test it. And we should have nice polymorphic objects and not string and nil and color why not array with hexa decimal colors? Being reasonable programmers and not kids wanted to plug anything anyhow is the way to build nice system (and polymorphic objects). Stef > On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> I'm in favor killing all the respondsTo: >> >> acceptTextMorphs >> "Accept any text morphs except for those that have no edits." >> >> self allMorphs do: [:p | >> ((p respondsTo: #accept) and: [ >> (p respondsTo: #hasUnacceptedEdits) and: [ >> p hasUnacceptedEdits]]) ifTrue: [p accept]] > > They're a step up from #isKindOf:. It looks like you need is something > that says "does this object respond to a particular set of messages > (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! > :) ) > > But in this particular case the solution looks like making a > #insertADecentNameHere that particular classes of things can implement > as "^ self hasUnacceptedEdits ifTrue: [self accept]" > > frank >

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Benjamin

Then you will have [ receiver strangeMessage ] on: Error do: [ receiver otherMessage on: Error do: [ self defaultFallback ] ] ^^ Ben On May 14, 2013, at 10:22 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > agrh!!!! > I would vote against it because slowly we would get this plague in the system. > > Stef > > On May 14, 2013, at 5:35 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> Something like >> >> self performIfExists: #blah >> >> would reduce the noise a lot :) >> Then in this methods, we do what we want ^^ >> >> Ben >> >> On May 14, 2013, at 5:32 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Hi >>>> >>>> I'm in favor killing all the respondsTo: >>>> >>>> acceptTextMorphs >>>> "Accept any text morphs except for those that have no edits." >>>> >>>> self allMorphs do: [:p | >>>> ((p respondsTo: #accept) and: [ >>>> (p respondsTo: #hasUnacceptedEdits) and: [ >>>> p hasUnacceptedEdits]]) ifTrue: [p accept]] >>> >>> They're a step up from #isKindOf:. It looks like you need is something >>> that says "does this object respond to a particular set of messages >>> (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! >>> :) ) >>> >>> But in this particular case the solution looks like making a >>> #insertADecentNameHere that particular classes of things can implement >>> as "^ self hasUnacceptedEdits ifTrue: [self accept]" >>> >>> frank >>> >> >

May 14, 2013

Re: [Pharo-dev] vm fixes

by Benjamin

Thank you :) This fix goes with pair with https://pharo.fogbugz.com/default.asp?10619 Thanks to Esteban, one can now deploy a Spec widget with the os window as window :) Ben On May 14, 2013, at 10:19 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > thanks esteban! > > On May 14, 2013, at 9:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> I just pushed fix for a weird bug in cocoa cog vm. >> It was crashing image when resizing using DisplayScreen>>#hostWindowSize: but even worst, some times was crashing also when dragging a window outside the world screen... >> >> The fix is there, but you will need to wait until tomorrow to have it in zeroconf (because of weird mac jenkins slave permissions). >> >> This increases a bit more the VM stability, still not perfect, but we are getting closer :) >> >> Esteban > >

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by stephane ducasse

agrh!!!! I would vote against it because slowly we would get this plague in the system. Stef On May 14, 2013, at 5:35 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Something like > > self performIfExists: #blah > > would reduce the noise a lot :) > Then in this methods, we do what we want ^^ > > Ben > > On May 14, 2013, at 5:32 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> I'm in favor killing all the respondsTo: >>> >>> acceptTextMorphs >>> "Accept any text morphs except for those that have no edits." >>> >>> self allMorphs do: [:p | >>> ((p respondsTo: #accept) and: [ >>> (p respondsTo: #hasUnacceptedEdits) and: [ >>> p hasUnacceptedEdits]]) ifTrue: [p accept]] >> >> They're a step up from #isKindOf:. It looks like you need is something >> that says "does this object respond to a particular set of messages >> (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! >> :) ) >> >> But in this particular case the solution looks like making a >> #insertADecentNameHere that particular classes of things can implement >> as "^ self hasUnacceptedEdits ifTrue: [self accept]" >> >> frank >> >

May 14, 2013

Re: [Pharo-dev] vm fixes

by stephane ducasse

thanks esteban! On May 14, 2013, at 9:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I just pushed fix for a weird bug in cocoa cog vm. > It was crashing image when resizing using DisplayScreen>>#hostWindowSize: but even worst, some times was crashing also when dragging a window outside the world screen... > > The fix is there, but you will need to wait until tomorrow to have it in zeroconf (because of weird mac jenkins slave permissions). > > This increases a bit more the VM stability, still not perfect, but we are getting closer :) > > Esteban

May 14, 2013

Re: [Pharo-dev] about theme and friends

by stephane ducasse

> Hi, > > I was rather thinking of having the theme be a composable factory: > - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory. Why a factory and not just the morph? > - the UITheme simply stores all these factories, and the morph looks the factory up via the theme. I do not get it. One key question is do we want to have the theme removable or not. Now if we would pushed only data through the hooks of the widgets it could work but we will have to be able to specify specific computation for a given widgets and theme. So may be this is what you mean by factory but this is still not clear to me. > - the UITheme will have no more subclasses. But you will have multiple subclasses of each of the factories? > - in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme. > > This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside. Yes but the GroupBoxFactory will also be out of the GroupBoxMorph so this is not clear to me how this is different > > Cheers, > Doru > > > > On May 14, 2013, at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Looking at the code I have the impression that many UITheme methods should be moved to the their classes >> >> Example: >> >> >> UITheme>>newGroupboxIn: aThemedMorph label: aString >> "Answer a groupbox with the given label." >> >> ^GroupboxMorph new >> font: self labelFont; >> cornerStyle: aThemedMorph preferredCornerStyle; >> hResizing: #spaceFill; >> vResizing: #spaceFill; >> label: aString; >> yourself >> >> Why this is not a creation method on GroupBox? >> >> Then the trait TeasilyThemed looks suspicious to me. >> >> >> > > -- > www.tudorgirba.com > > "Presenting is storytelling." > >

May 14, 2013