IMO the most important consideration should be readability: one should be able to guess what the method does without having to look how it is implemented, which means that the naming is crucial.

To me *personally* it is not intuitive what is meant by anObject if: aBlockOrSelector do: aBlock elseDo: anotherBlock. It is no clearer to me than if:then:else:

To really be clear I would prefer something like anObject ifEvaluatesToTrueUsing: aBlockOrSelector then: aBlock else: anotherBlock. Now there's no guesswork involved, and the code is readable to anyone.

Just my $0.02 ;-)

On Tue, Jun 18, 2013 at 1:35 PM, kilon <thekilon@yahoo.co.uk> wrote:

What I think. Well the point of Smalltalk is that it offers you a language
that allows you to play with the syntax. Thats pretty much the heart of
Smalltalk. So I would definitely not be against offering an alternative to
if conditions.

Personally I have no problem with the original syntax. I would not use temp
variables I would instead create methods that returned those blocks. This
way I hide away verbosity of code and the user can easily browse those
blocks using the IDE.

Its definitely a good thing to explore alternative ways of doing things.
However smalltalk coders should not be afraid to introduce new language
features that may seem weird. If the documentation is good , people wont
have a hard time understand it unless its a really complex feature.

I am very new to smalltalk I found blocks a lot more strange than
ifTrue:/ifFalse: yet it did not take me more than 2 minutes to figure things
out. �Of course maybe there is even a better alternative than what you offer
and what standard syntax already offers out there, waiting to be found ;)

--
View this message in context: http://forum.world.st/Pharo-dev-Object-if-then-else-tp4693871p4693889.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Cheers,