Yes, when the compiler sees exp or: [ ... ] then it assumes that "exp" is a boolean-valued expression and generates code that fails if it isn't. Not all Smalltalk compilers perform this optimization, but it is very common. There are a bunch of methods treated like this, ifTrue:ifFalse: is another.
whileTrue: is an interesting slightly different case. The compiler usually optimizes whileTrue: only when both receiver and the argument are blocks. So, you can define whileTrue: in other classes without any problem.
-Ralph Johnson
On Sun, Sep 10, 2017 at 6:33 AM, Lorenz Köhl rainbowtwigs@gmail.com wrote:
[image: Boxbe] https://www.boxbe.com/overview This message is eligible for Automatic Cleanup! (rainbowtwigs@gmail.com) Add cleanup rule https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dd8UdKk6XBKefiw6WgR5jxiRs%252Bz4ZhdYH4NLF8y3Q1yo%253D%26token%3DCBHKUay%252FXiASnIShRk4i8Xwq5eeRqmxypuV1cDN%252BApJJ2u4Z4%252FQyrGmN6UBKpep9V2BaY%252FdQlkUFgiXKdY2jjkjIPnsaoNhAT20BWqPqLuX%252FZk%252BKFBJtacqPIMXss6tKcVEsQBe%252FncsPJAsw1rMWyw%253D%253D&tc_serial=32680703685&tc_rand=509028261&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001 | More info http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=32680703685&tc_rand=509028261&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001
I don't understand why Smalltalk doesn't allow me to have an or: method that takes a block argument (except on Boolean). For example:
Set or: 1. ==> MNU as expected.
Set or: [1]. ==> NonBooleanReceiver exception.
Set or: [:x | x] ==> Argument has too many arguments
Is it because the compiler specializes this to boolean when it sees the or: [ ... ] syntax? Is this a tradeoff made for performance?
greetings, Lorenz
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners