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 <[email protected]> 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
>
