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,