I do not like it :) 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: Esteban On Jun 18, 2013, at 1:05 PM, Goubier Thierry <thierry.goubier@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