On 18 June 2013 12:35, Goubier Thierry <[email protected]> wrote:
>
>
> Le 18/06/2013 13:09, Esteban Lorenzano a écrit :
>
>> 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 ] ]
>
>
> This is cool :) Didn't knew about this one.
It's a lot like `let` in other languages (Haskell, the Lisps, and so on).
> Could we use do: in the same way ? Because in: is in a way the same as
>
> {<my complex expression>} do: [ :blah |
>
> blah = myTest
> ifTrue: [ blah some ]
> ifFalse: [ blah other ] ]
>
> With a different return value.
No: #do: signals that you're doing something entirely for a side
effect. But if you said `{<my complex expression} collect: [:blah |
...]` then I'd agree with you.
> Thierry
>
>
>> 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
>>>
>>
>>
>>
>>
>
> --
> 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
>
