On 18 juin 2013, at 13:09, Esteban Lorenzano wrote: > I do not like it :) I understand that (especially from a conservative who doesn't even like colors ;D ).
> > also, you already have #in: > which is more generic and allows simplifications: > > <my complex expression> in: [ :blah | > blah = myTest > ifTrue: [ blah some ] ] > ifFalse: [ blah other ] ] > > and also the advantage is that you are not restricted to #ifTrue:ifFalse: Yes I love #in: , that was my inspiration. if:do:, if:do:elseDo: and while:do: would just be a bit of sugar to use sparingly just like in:. > > Esteban > > On Jun 18, 2013, at 1:05 PM, Goubier Thierry <thierry.goub...@cea.fr> wrote: > >> >> >> Le 18/06/2013 12:27, Camille Teruel a écrit : >>> >>> On 18 juin 2013, at 11:20, Goubier Thierry wrote: >>> >>>> Hi Camille, >>>> >>>> It's not bad as things goes, because it does look a bit like >>>> non-smalltalk code (i.e. the if then else structure) except that the >>>> precise meaning is very much Smalltalk : >>> >>> Ok the name may be confusing. >>> So if you rename it to something like #if:do:elseDo:, it would be more >>> smalltalkish and there is no confusion with classical if-then-else. >> >> Maybe, that would help. >> >>>> if: has a receiver, and there is a not so intuitive relationship >>>> between the bloc parameters and the receiver. >>> >>> Talking to an arbitrary object is the goal, since booleans are not very >>> talkative kind of object. >>> Compare >>> >>> | temp | >>> temp := <complexExpression> >>> temp isNil ifTrue: [...] ifFalse: [... temp ...] >>> >>> with: >>> >>> <complexExpression> ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...] >>> >>> ifNil:ifNotNil: is not better only because it is shorter, it is better >>> because I am talking to the object I am auditing, not a stupid boolean >>> that knows nothing else but its truth value. >> >> Yes, but I know firsthand (because I used Smalltalk before that idiom was >> introduced) that it represent one more idiom to learn, and it's still not >> familiar. >> >> The same goes with withStreamDo: or what is that idiom again I sometimes >> encounter. >> >>>> Honestly, as far as code reviews goes, I'll prefer the temp >>>> refactoring. Understandable without having to search for the >>>> implementors of #if:then:else: >>> >>> I know this would break a long time tradition and people may not like >>> it, so that's a question of taste and style, not understandability. >>> There would be only one implementor, the implementation is really simple >>> and the selector is explicit. >> >>> Anyone can get use to it in less than 2 min. >> >> It's one more thing to get used to and to explain to beginners in say 10 >> minutes per idiom... (describe, give an example, let them practice, rinse >> and repeat for each idiom). >> >> Add all the new idioms and, instead of explaining Smalltalk in half a day, >> you spend a few days doing explaining all those idioms and not doing more >> interesting stuff. >> >> Soon, you end up like ocaml, where your minimum introduction time is a week, >> not half a day. >> >>> Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse: >>> ,... every time? >> >>> No because people learned what they do when they learned Smalltalk, and >>> I'm sure it didn't get them more than a few minutes. >> >> Yes, but add the ifNil: ifNotNil:, stream thingies I never remember, your >> variant of if-else, and, and ... On some of those, I have to look for the >> implementors, and I'm really happy to benefit from the smart suggestions in >> the new browsers. (Additionally, code patterns using cull: in pharo more >> often than not are very poorly documented about the arguments that are given >> to the block). >> >> Smalltalk is disruptive enough as it is (and still is after all those years) >> to try not to make it more complex. I'd prefer efforts making obvious really >> complex patterns instead of idioms with a not so great cognitive load to >> effectiveness. >> >> I'd be happy to have a shorter list of methods and extensions on Object, as >> well :) >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des Systèmes Temps Réel Embarqués >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >
