- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by Marcus Denker

> On 02 Sep 2015, at 12:32, stepharo <stepharo(a)free.fr> wrote: > > Hi guille > > there is not stress. I just wanted to let you know. > I was wondering if just subclassing DateAndTime would not be enough for now. Yes, as far as I remember Timestamp was just an empy subclass. We could: -> add it back to Deprecated50 or maybe even to a âCompatibilityâ package -> Write a Quality Check rule. > I will go back to code with Pharo 40 > > stef > > Le 2/9/15 10:30, Guillermo Polito a Ã©crit : >> If somebody can check it and fix it it would be good :). I've just started my new job and my evenings are busy looking for an apartment or staying in a hostel without a proper internet connection... >> >> If not, I think we can wait a bit. The first step should be enabling CI jobs for pharo5. Also, I do not think the intersection between 'people using garage opendbx' and 'people using pharo5' is that big to justify a rush. >> >> Guille >> >> El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: >> for your info... >> >> Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp >> >> Stef >> >

Sept. 2, 2015

Re: [Pharo-dev] widgetDo: vs ifWidget:

by Peter UhnÃ¡k

In that case I rest my case and I will stick with #widgetDo: :) Not even the naming. I would say. lot of code in spec should be rewritten. > The holder should be most of the time directly exposed to reduce the API. I know; it is moving, albeit slowly. Thanks, Peter

Sept. 2, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by stepharo

Hi guille there is not stress. I just wanted to let you know. I was wondering if just subclassing DateAndTime would not be enough for now. I will go back to code with Pharo 40 stef Le 2/9/15 10:30, Guillermo Polito a Ã©crit : > If somebody can check it and fix it it would be good :). I've just > started my new job and my evenings are busy looking for an apartment > or staying in a hostel without a proper internet connection... > > If not, I think we can wait a bit. The first step should be enabling > CI jobs for pharo5. Also, I do not think the intersection between > 'people using garage opendbx' and 'people using pharo5' is that big to > justify a rush. > > Guille > > El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo > <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: > > for your info... > > Garage-OpenDBX does not load on Pharo 50 because it uses > Timestamp > > Stef >

Sept. 2, 2015

Re: [Pharo-dev] widgetDo: vs ifWidget:

by stepharo

Le 2/9/15 10:56, Peter UhnÃ¡k a Ã©crit : > Hi, > > in Spec Adapter there's method > > widgetDo: aBlock > ^ self widget ifNotNil: aBlock > > > my question however is: > does the naming make sense? > > #*Do: is generally associated with iterating over collections. Widget > is always a single entity. > On the other hand we have #ifNil: #ifTrue: #ifFalse: > > There is also #ifNotNilDo:, however that is superseded by #ifNotNil: > > So from this perspective, wouldn't it make more sense to have this? > ifWidget: aBlock > ^ self widget ifNotNil: aBlock I prefer widgetDo: because this if logic is not really good and the user should not be exposed > > What do you think? > > Thanks, > Peter

Sept. 2, 2015

Re: [Pharo-dev] widgetDo: vs ifWidget:

by stepharo

Le 2/9/15 10:56, Peter UhnÃ¡k a Ã©crit : > Hi, > > in Spec Adapter there's method > > widgetDo: aBlock > ^ self widget ifNotNil: aBlock > > > my question however is: > does the naming make sense? Not even the naming. I would say. lot of code in spec should be rewritten. The holder should be most of the time directly exposed to reduce the API. > > #*Do: is generally associated with iterating over collections. Widget > is always a single entity. > On the other hand we have #ifNil: #ifTrue: #ifFalse: > > There is also #ifNotNilDo:, however that is superseded by #ifNotNil: > > So from this perspective, wouldn't it make more sense to have this? > ifWidget: aBlock > ^ self widget ifNotNil: aBlock > > What do you think? > > Thanks, > Peter

Sept. 2, 2015

Re: [Pharo-dev] widgetDo: vs ifWidget:

by Aliaksei Syrel

The same naming blablaDo: is heavily used in Bloc and therefore in Brick. I personally like blablaDo: more, because it hides check logic from user and doesn't force to think about if-elses. It's all about "if" word. You know, when reader sees "if" a complexity of an app instantly rises (in the head). But let's discuss :) I agree that it can be associated with iteration and is not the best idea... Cheers, Alex On Wed, Sep 2, 2015 at 10:56 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > in Spec Adapter there's method > > widgetDo: aBlock > ^ self widget ifNotNil: aBlock > > > my question however is: > does the naming make sense? > > #*Do: is generally associated with iterating over collections. Widget is > always a single entity. > On the other hand we have #ifNil: #ifTrue: #ifFalse: > > There is also #ifNotNilDo:, however that is superseded by #ifNotNil: > > So from this perspective, wouldn't it make more sense to have this? > ifWidget: aBlock > ^ self widget ifNotNil: aBlock > > What do you think? > > Thanks, > Peter >

Sept. 2, 2015

Rubric #mouseDown, #mouseUp and #click

by Stephan Eggermont

We have a few morphs where #on:#mouseDown send: aMessage to: aTarget is used where I'd expected that to be on #click. Mostly in Rubric and the Nautilus annotations If a morph is supposed to behave as a button, the action should happen on the #mouseUp, but only if the mouse pointer hasn't moved away from the morph. That is what #click does. And ExpanderTitleMorph GrowlMorph JobProgressMorph react on #mouseUp instead of #click Stephan

Sept. 2, 2015

widgetDo: vs ifWidget:

by Peter UhnÃ¡k

Hi, in Spec Adapter there's method widgetDo: aBlock ^ self widget ifNotNil: aBlock my question however is: does the naming make sense? #*Do: is generally associated with iterating over collections. Widget is always a single entity. On the other hand we have #ifNil: #ifTrue: #ifFalse: There is also #ifNotNilDo:, however that is superseded by #ifNotNil: So from this perspective, wouldn't it make more sense to have this? ifWidget: aBlock ^ self widget ifNotNil: aBlock What do you think? Thanks, Peter

Sept. 2, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by Guillermo Polito

If somebody can check it and fix it it would be good :). I've just started my new job and my evenings are busy looking for an apartment or staying in a hostel without a proper internet connection... If not, I think we can wait a bit. The first step should be enabling CI jobs for pharo5. Also, I do not think the intersection between 'people using garage opendbx' and 'people using pharo5' is that big to justify a rush. Guille El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo <stepharo(a)free.fr> escribiÃ³: > for your info... > > Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp > > Stef > >

Sept. 2, 2015

Re: [Pharo-dev] Removing name from Object

by Esteban Lorenzano

but if we deprecate, that means we need to remove it from the system. deprecated is for external users, not for Pharo it self. Esteban ps: We *can not* remove #name from the system just like that. It is too widely use, we need to give users time to adapt. Doing otherwise is not professional and expect a lot of people yelling (and with reason, in this case). > On 02 Sep 2015, at 10:21, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > The problem is if (like in the past) name is extensively used by some library we depend upon (like... let's say morphic), a deprecation that raises an exception may turn the system unusable. It's not that it is not doable, but we should do it gently and with love. > > El miÃ©., 2 de sept. de 2015 a la(s) 9:30 a. m., Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> escribiÃ³: >> On 02 Sep 2015, at 09:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >> On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> How can we find out, which external projects depend on this? >> >> Is #name in any way special? Why not just deprecate it like any other method change or removal? (And then remove it in Pharo 6) > > +1 > thatâs the way to do it :) > >> >> Peter >

Sept. 2, 2015