>  cascade operator.  You don't like it, but it still provides
> something that requires temporary variables to duplicate without it.
>

Duplicate... don't know. I think one temporary variable per activation
should be enough, because you can overwrite it.

> You state that it isn't needed because most of the message sends
> return self anyway, and this may in fact be true.  But it might also
> be wrong.  The cascade operator is a guarantee; I don't have to worry
> *what* the message send returns because I know the other messages I'm
> cascading go to the original object no matter what.
>
> Coming from a functional background, I'm sure you can appreciate the
> value of such a guarantee. :)
>

I can see that.
But ... for example.

collection := OrderedCollection new.
collection add:1.

evaluates to one. Why ? Why not to collection ?

The collection library has been designed around the mechanics of the  
cascade operator.
I need to now why.

to me adding the ";" for...

collection add:1; add:1; add:1; yourself.

it's not enough.

collection add:1 | add: 1 | add:1

at the cost (probably) of one more temporary. Considering the cost  
reflection, it's nothing.
Who cares of the overhead of one temp?

I need things like functional composition ... that is a big thing.
functional composition is a GOOD reason for adding an operator.  
Consider this: if you
were adding an operator in perl who cares. One more, one less. It  
doesn't make any difference.
But in Smalltalk especially because is so small ... adding an  
operator is BIG thing.

By doing that you are making quite a big statement to the users. If  
it was perl than it would
be just ... "guys here is another one".


But not in Smalltalk.
To me it's like a godly voice saying ...
"You shall use the mighty cascade operator .."

and I say, ..."alright, let me see what cool things I can do ..." and  
the best thing I come up is ...

collection add:1; add:1; add:1; yourself.

mmm ...

If you do the same thing with the Pipe ... instead ... at least to  
me ...

the big godly statement is

"You shall combine your object's methods"
or
"You shall use functional programming"

> The cascade operator is a guarantee; I don't have to worry
> *what* the message send returns because I know the other messages I'm
> cascading go to the original object no matter what.
>

If you need guarantees than a strongly typed language is better.
Why not having guarantees on types etc ... ?
A working test is enough of a guarantee.

Usually you don't worry about that

10 :append 10

fails,  is it ?

Why you worry that this could fail...
collection add:1 | add: 1 | add:1


We got tests to take care of those problems.

Smalltalk-80 is Smalltalk-80, with all it's libraries and design  
decisions.
And that is fine. Cascade won't go away from there.

But in a new Smalltalk ? would you keep it ? is there any reason
we NEED the ";" operator ? or is just because it's now common use ...

We do need the pipe, IMHO, for functional compositions.
We do need the cascade operator ... for ... for what ?

Not to break libraries and to have a cross vendor smalltalk ... is ok.
then for what... I can't cover all cases of the cascade operator but  
something
tells me that I might be able to reproduce the work ";" just be  
using ... an implied protocol.

like ...

collection add:1; add:1; add:1; yourself.

well just say .. "in a new hypothetical ST we do it this way ..."

collection add:1 | add: 1 | add:1

and overall the "|" could do the same thing and that other cases  
could be covered with another desing
that would be extremely clean anyway.

> Your aggressive language comes off as blame, etc.  And please stop
> saying "the cascade operator sucks".

Fair enough. I'll be more careful. But, if we where talking face to  
face you would see
a smile on my face not an ... aggressive face.

"The cascade operator sucks" ... ops... :o)

Joking. I apologize to everybody for my language.
Let me re-frase: if we would design today a NEW Smalltalk,  the  
cascade operator might be an
argument of discussion.

> It's pure opinion and utterly
> irrelevant to the discussion of whether or not  we need a "pipe"
> statement delimiter.

I tried to motivate quite a lot my opinion.
I might say from my point of view it's pure opinion wether you NEED  
or not a "cascade" statement delimiter.

I might even get convinced otherwise with some examples ... !!!

At least I have tried to expose an issue with concrete examples on  
why the pipe is so important. No examples have come to defend the  
cascade... of course in a context of a new Smalltalk.

This pipe thing is repeated in history too. Haskell's monads are not  
really a pipe thing, but the monadic bind (>>=) operator is really  
close to that.










-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070826/a518513b/attachment.htm