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

Re: [Pharo-dev] Object >> #is:

by Igor Stasenko

On 25 June 2013 14:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-06-25, at 14:35, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 25 June 2013 14:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> On Jun 25, 2013, at 1:36 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 25 June 2013 13:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> I really cannot believe that you can consider >>>>> >>>>> is: #string >>>>> >>>>> better programing than >>>>> >>>>> isString >>>>> >>>>> no matter the implementation, and no matter if you can still found senders of #string... string programming (or symbol programing) is just bad, bad, bad. >>>>> Is so bad that is axiomatic... I cannot even explain why... :) >>>>> >>>> >>>> you are highly subjective here. :) >>>> >>>> given two expressions: >>>> >>>> object isString >>>> and >>>> object is: #string >>>> >>>> to me they are equal in their beautiness or ugliness, if you like. >>> >>> with the difference that in one: >>> >>> 1) you has a clearer and more expressive message >>> 2) you have a simple message send with an immediate return (and not a comparisson) >>> >>> and in the other... you don't. >>> >> >> But that's exactly the point: if you so bad, that end up using isXXXX >> pattern in your code, >> you have to pay extra price for it! >> See, you don't like it! This is intentional! So, you should think how >> to avoid using it, >> and be forced to write better code :) >> >> Consider #is:, like anti-method for anti-pattern.. >> but not as "a very useful method". >> Then everything will fit on its place in your mind! :) > > > so that's why you install so many NativeBoost methods on Object?? > > invest your motivation into athens and txtext that is way more productive... i cannot, while [someone is wrong on the internet] :)) yeah.. i think this is enough. -- Best regards, Igor Stasenko.

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Camille Teruel

On 25 juin 2013, at 13:22, Igor Stasenko wrote: > On 25 June 2013 12:59, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> On 25 juin 2013, at 11:45, Igor Stasenko wrote: >> >> On 25 June 2013 11:09, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> >> On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: >> >> >> >> On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> >> >> On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> >> >> the isBlah is not optimal now it is just there and we cannot rewrite >> >> everything. >> >> >> I still think that is: is a nice way to kill some of the isPlague in Object. >> >> >> >> I still don't see what you solve, and the idea to use symbols for #is: is >> >> also >> >> >> wrong, for me that's going back to string-based programming. >> >> >> >> well, that's basically my argument agains #is: >> >> IMO is also an important performance issue in many cases, because is >> >> replacing a simple send with a string comparison and that can provoke >> >> slowdowns in some places (no idea where, this is just theoretical :)... >> >> Of course, as "pharo designers" we should be careful on not overpopulate >> >> Object with isBlah methods... but sometimes they are needed :) >> >> >> >> +1. >> >> Indeed, sometimes they are needed. You can't replace every isXXX send with a >> >> new visitor or dispatching by adding more and more extension methods all >> >> over the place (including Object BTW). >> >> Yet a fair amount of these methods can be removed. >> >> I think that a lot of these methods exist only because people think that >> >> isKindOf:/isMemberOf: are always evil, and its not true. >> >> There is at least three cases were I don't feel guilty using >> >> isKindOf:/isMemberOf: : >> >> - In unit tests >> >> - In #= methods >> >> - When I really want to ensure that an object is an instance of a specific >> >> class (see MethodContext>>#privRefreshWith: for example). This poor's man >> >> type checking can be replace with typed slots (that end up using >> >> isKindOf/isMemberOf: anyway). >> >> If we agree on that we can remove many #isXXX methods. >> >> Then there is some #isXXX methods that do not belong to Object (ex: >> >> #isTransferable belongs to Morph) and others that can be removed just by >> >> refactoring senders. >> >> We can also move some of them to extension methods, that doesn't solve the >> >> problem but it's a better packaging. >> >> Anyway I don't want to rely on #is: method because it conflates a lot of >> >> selectors into one. >> >> >> yes. it is. so what is the problem? >> >> >> The problem is that this #is: method is like aspirin: it makes the symptom >> disappear but it doesn't cure the disease (if there is one). >> > > Why? It was proposed how to deal with too many isXXXX methods in Object class. > It is orthogonal to whether you should use isXXX pattern or not. > Because each case should be dealt separately (and that's where you > free to override #is: method > to serve your special purpose). > >> Are you sure you understand the purpose of #is: method? >> >> >> No I didn't, but now that you revealed me the true purpose of #is:, I >> finally reached enlightenment. >> But apparently it's not the case of its own comment. >> > Despite the method's comment contains my name, it is not under my authorship. I never said it was. > Look for mailing list archives to see what i proposed then, and if it > different to what i saying now. I believe you. The link to the archive is dead BTW. > >> "A means for cleanly replacing all isXXX like methods. >> Please use judiciously! >> Suggested by Igor Stasenko at >> >> all isXXX should be converted following the pattern >> ColorForm>>isColorForm >> ^ true >> Object>>isColorForm >> ^ false >> is: aSymbol >> ^ aSymbol = #ColorForm or: [ super is: aSymbol ]" >> >> its purpose is for cases when you realy realy very very badly want to >> add own isPlague to >> Object protocol. In that case, you should use 'is: #plague' >> because no new isXXXX methods should be added anymore. >> The feast is over, and you should use #is: method. (or think how to >> not use isXXX pattern at all). >> >> >> TL;DR: I agree with Camillo :) >> >> >> >> anyway, this topic has been discussed with enough hot air so far and no >> >> progress, >> >> >> which means it is absolutely not important. there are more urgent things to >> >> done... >> > > i could not care less.. Back in 2009 i just proposed this. > Pharo people seems liked the idea and added this method into the image. > That's how my name appeared there. > And what i trying to (again as in 2009) articulate here, is how i see > to use this method. > But NOT whether it should stay in image or to be gone. > > > > -- > Best regards, > Igor Stasenko. >

June 25, 2013

Re: [Pharo-dev] [update 2.0] #20608

by Martin Dias

Nice. What you fixed was a problem since the inception of fuel. About the new hook #fuelReplacement, it's cool to have it. We should add it to our doc. It seems to implement something that Eliot suggested two years ago* :) *: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050300.html Cheers Martin On Tue, Jun 25, 2013 at 2:08 PM, Max Leske <maxleske(a)gmail.com> wrote: > My pleasure :) > > > On 25.06.2013, at 14:06, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Cool!!! Thanks for all your effort Max > > > On Tue, Jun 25, 2013 at 7:10 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> Yay! 1.9.1 has been integrated into 2.0. >> >> Cheers, >> Max >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > On Tue, Jun 25, 2013 at 12:12 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 25.06.2013, at 11:33, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> 20608 >> ----- >> >> 10888 Backport 2.0: Compound Extension Methods Unpackaged >> https://pharo.fogbugz.com/f/cases/10888/Backport-2-0-Compound-Extension-Met… >> >> 10730 Fix for stack serialization with Fuel >> https://pharo.fogbugz.com/f/cases/10730/Fix-for-stack-serialization-with-Fu… > > Thanks Esteban! > >> >> 10994 Backport 2.0: Delays do not work properly directly on image startup >> https://pharo.fogbugz.com/f/cases/10994/Backport-2-0-Delays-do-not-work-pro… >> >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/RPackage-Tests-EstebanLorenzano.111.diff >> http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-EstebanLorenzano.216.diff >> http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1348.diff >> http://ss3.gemstone.com/ss/Pharo20/FuelTests-EstebanLorenzano.316.diff >> http://ss3.gemstone.com/ss/Pharo20/Fuel-EstebanLorenzano.767.diff >> >> > >

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Camillo Bruni

On 2013-06-25, at 14:35, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 June 2013 14:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> On Jun 25, 2013, at 1:36 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 25 June 2013 13:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> I really cannot believe that you can consider >>>> >>>> is: #string >>>> >>>> better programing than >>>> >>>> isString >>>> >>>> no matter the implementation, and no matter if you can still found senders of #string... string programming (or symbol programing) is just bad, bad, bad. >>>> Is so bad that is axiomatic... I cannot even explain why... :) >>>> >>> >>> you are highly subjective here. :) >>> >>> given two expressions: >>> >>> object isString >>> and >>> object is: #string >>> >>> to me they are equal in their beautiness or ugliness, if you like. >> >> with the difference that in one: >> >> 1) you has a clearer and more expressive message >> 2) you have a simple message send with an immediate return (and not a comparisson) >> >> and in the other... you don't. >> > > But that's exactly the point: if you so bad, that end up using isXXXX > pattern in your code, > you have to pay extra price for it! > See, you don't like it! This is intentional! So, you should think how > to avoid using it, > and be forced to write better code :) > > Consider #is:, like anti-method for anti-pattern.. > but not as "a very useful method". > Then everything will fit on its place in your mind! :) so that's why you install so many NativeBoost methods on Object?? invest your motivation into athens and txtext that is way more productive...

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Igor Stasenko

On 25 June 2013 14:21, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > I agree with Esteban here, I think we just have to agree to disagree :) > To me as well, is: #Number reads 100x worse than isNumber. > > On Jun 25, 2013, at 12:33 PM, Igor Stasenko wrote: > > > In general, the more methods we put into Object, the higher > probability of name clashing (two projects using same selector > for method in Object but for different purpose). > It also slows down the lookup time, because VM checks every method > dictionary, including Object. > (not speaking of slowing down UI ;) > > > Really? I thought this was one of the things PIC's are good at for where it > matters, only recording cases for objects actually sent the message from a > call site. > (Not that that's a big consolation for isMorph and other abuses of > inheritance/polymorphism, but still...) > Sure, thing. But PICs are not permanent (and interpreter doesn't have them). With cache you can avoid like 85%? of cases.. but for 15% VM still does lookup. And all caches tend to be flushed periodically.. And then you pay the price of bloated method dictionary :) > Cheers, > Henry -- Best regards, Igor Stasenko.

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Igor Stasenko

On 25 June 2013 14:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Jun 25, 2013, at 1:36 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 25 June 2013 13:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> I really cannot believe that you can consider >>> >>> is: #string >>> >>> better programing than >>> >>> isString >>> >>> no matter the implementation, and no matter if you can still found senders of #string... string programming (or symbol programing) is just bad, bad, bad. >>> Is so bad that is axiomatic... I cannot even explain why... :) >>> >> >> you are highly subjective here. :) >> >> given two expressions: >> >> object isString >> and >> object is: #string >> >> to me they are equal in their beautiness or ugliness, if you like. > > with the difference that in one: > > 1) you has a clearer and more expressive message > 2) you have a simple message send with an immediate return (and not a comparisson) > > and in the other... you don't. > But that's exactly the point: if you so bad, that end up using isXXXX pattern in your code, you have to pay extra price for it! See, you don't like it! This is intentional! So, you should think how to avoid using it, and be forced to write better code :) Consider #is:, like anti-method for anti-pattern.. but not as "a very useful method". Then everything will fit on its place in your mind! :) > but well, I already explained my opinion... and I think we are not going to agree. > So I rest, I'm over of this :) > -- Best regards, Igor Stasenko.

June 25, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testWikimedia

June 25, 2013

Re: [Pharo-dev] looking at initialization of LayoutProperties :)

by Igor Stasenko

On 25 June 2013 11:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Morph>>assureLayoutProperties > | props | > props := self layoutProperties. > props ifNil:[ > props := LayoutProperties new initializeFrom: self. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > self layoutProperties: props]. > ^props > > > LayoutProperties >> initializeFrom: defaultProvider > "Initialize the receiver from a default provider" > self hResizing: defaultProvider hResizing. > self vResizing: defaultProvider vResizing. > self disableTableLayout: defaultProvider disableTableLayout. > > ok up here. > > Morph>>hResizing > "Layout specific. This property describes how the receiver should be resized with respect to its owner and its children. Possible values are: > #rigid - do not resize the receiver > #spaceFill - resize to fill owner's available space > #shrinkWrap - resize to fit children > " > | props | > props := self layoutProperties. > ^props ifNil:[#rigid] ifNotNil:[props hResizing]. > > > arghâ¦. > > Stef things which you can easily do in prototype-based system, not easy in class-based. Here, i think a side effect of porting Morphic from self to smalltalk. So, in prototype-based system, a prototype could have a default property (like hResizing) and hold some default value (#rigid, for instance)... like that, all objects which inherit from that one, will also inherit this property. But if one would like to set it, it will set new value of this property, but not in prototype, but actually in object which you sent message to. That's why all this dance with ifNil: ... -- Best regards, Igor Stasenko.

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Henrik Johansen

I agree with Esteban here, I think we just have to agree to disagree :) To me as well, is: #Number reads 100x worse than isNumber. On Jun 25, 2013, at 12:33 PM, Igor Stasenko wrote: > > In general, the more methods we put into Object, the higher > probability of name clashing (two projects using same selector > for method in Object but for different purpose). > It also slows down the lookup time, because VM checks every method > dictionary, including Object. > (not speaking of slowing down UI ;) Really? I thought this was one of the things PIC's are good at for where it matters, only recording cases for objects actually sent the message from a call site. (Not that that's a big consolation for isMorph and other abuses of inheritance/polymorphism, but still...) Cheers, Henry

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Esteban Lorenzano

On Jun 25, 2013, at 1:36 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 June 2013 13:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> I really cannot believe that you can consider >> >> is: #string >> >> better programing than >> >> isString >> >> no matter the implementation, and no matter if you can still found senders of #string... string programming (or symbol programing) is just bad, bad, bad. >> Is so bad that is axiomatic... I cannot even explain why... :) >> > > you are highly subjective here. :) > > given two expressions: > > object isString > and > object is: #string > > to me they are equal in their beautiness or ugliness, if you like. with the difference that in one: 1) you has a clearer and more expressive message 2) you have a simple message send with an immediate return (and not a comparisson) and in the other... you don't. but well, I already explained my opinion... and I think we are not going to agree. So I rest, I'm over of this :) > > >> and that just because we do not like to have 20 methods (or whatever the number) isBlah in object? >> >> sorry, I completely disagree with the idea. >> >> now, I agree that some of the "is" methods should be removed, but that is a complete different discussion :) >> > right. but that was the proposal to remove them first (by replacing with #is:) > and then gradually deal with them later (but already having cleaned > Object protocol). > >> Esteban >> > > > -- > Best regards, > Igor Stasenko. >

June 25, 2013