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