On 8/27/07, Igor Stasenko <siguctua at 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.