On 8/27/07, Igor Stasenko siguctua@gmail.com wrote:
Cascade is useful. It allows me to write code like that: ogl glTexParameteri: GLTexture2d with: GLTextureMinFilter with: GLLinear; glTexParameteri: GLTexture2d with: GLTextureMagFilter with: GLLinear; glTexParameteri: GLTexture2d with: GLTextureWrapS with: GLClamp; glTexParameteri: GLTexture2d with: GLTextureWrapT with: GLClamp; glPixelMapfv: GLPixelMapIToA with: 2 with: (FloatArray with: 0.0 with: 1.0).
But at the same time it stinks because you don't using the evaluation result of previously sent message, you simply drop it. And from this point i feel that something wrong with such design. Why computer needs to waste cycles to evaluate result of message when its simply not used at the end?
What are you talking about? ; and . are both sequencing operators. Sequencing implies that a statement was not for it's results, but it's side effects. And some systems even detect if the result is used and drop it if not.
And it's not that cascade "drops" something, it just signals that you want the original object instead of the result of the message send. If you want the result of the message send you have it, just send your message (though parens may be needed to indicate this is a new message).
In contrast , a pipe does not drops evaluation result, but reuses it in expression that follows. From this point i like it more than cascade.
No it doesn't. It just tells the compiler to treat everything to the left a complete expression, without having to use parenthesis.
And it also makes the original object inaccessible, forcing you (in some cases) to use temp variables and more of these "side effect" statements that you don't seem to like.
Same with period '.' Each time you placing a period in code, you telling compiler to drop the evaluated result of your expression. Can it be considered as good from computational point of view? Of course its not. You forcing a computer to waste the cycles just for nothing.
Not strictly true.
Same with implicit return self from a method. I see a good reasons why i don't want return anything from a method, because it returns nothing useful or meaningful, and never used for continue evaluation in other expressions.
But it might be saved in some variable, what happens then? Someone is going to be quite surprised to get a nil from a method that succeeded.
And i think that maybe from computational point of view, it might be useful to indicate if we need to return result from a method or don't.
If it were even possible to know I still wouldn't find the unmeasurably small gains worth the added complexity.
So, all messages which chained in cascade expressions can be sent with flag 'drop result=true' and same for messages which is the last before period '.'. In other words we can have two forms of 'send' operation (bytecode): Send with return and send without return.
This could be done today (if a bytecode existed for it) by the compiler which actually sees if the value is used or not.