<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica"> cascade operator.<SPAN class="Apple-converted-space"> </SPAN>You don't like it, but it still provides</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">something that requires temporary variables to duplicate without it.</FONT></P></BLOCKQUOTE><BLOCKQUOTE type="cite"><BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Duplicate... don't know. I think one temporary variable per activation </DIV><DIV>should be enough, because you can overwrite it. </DIV><BR><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">You state that it isn't needed because most of the message sends</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">return self anyway, and this may in fact be true.<SPAN class="Apple-converted-space"> </SPAN>But it might also</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">be wrong.<SPAN class="Apple-converted-space"> </SPAN>The cascade operator is a guarantee; I don't have to worry</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">*what* the message send returns because I know the other messages I'm</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">cascading go to the original object no matter what.</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Coming from a functional background, I'm sure you can appreciate the</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">value of such a guarantee. :)</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I can see that. </DIV><DIV>But ... for example.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>collection := OrderedCollection new.</DIV><DIV>collection add:1.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>evaluates to one. Why ? Why not to collection ?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The collection library has been designed around the mechanics of the cascade operator.</DIV><DIV>I need to now why.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>to me adding the ";" for...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>collection add:1; add:1; add:1; yourself.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>it's not enough.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>collection add:1 | add: 1 | add:1</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>at the cost (probably) of one more temporary. Considering the cost reflection, it's nothing. </DIV><DIV>Who cares of the overhead of one temp? </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I need things like functional composition ... that is a big thing.</DIV><DIV>functional composition is a GOOD reason for adding an operator. Consider this: if you</DIV><DIV>were adding an operator in perl who cares. One more, one less. It doesn't make any difference.</DIV><DIV>But in Smalltalk especially because is so small ... adding an operator is BIG thing.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>By doing that you are making quite a big statement to the users. If it was perl than it would</DIV><DIV>be just ... "guys here is another one". </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>But not in Smalltalk.</DIV><DIV>To me it's like a godly voice saying ...</DIV><DIV>"You shall use the mighty cascade operator .." </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>and I say, ..."alright, let me see what cool things I can do ..." and the best thing I come up is ...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>collection add:1; add:1; add:1; yourself.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>mmm ...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If you do the same thing with the Pipe ... instead ... at least to me ...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>the big godly statement is </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>"You shall combine your object's methods"</DIV><DIV>or</DIV><DIV>"You shall use functional programming"</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The cascade operator is a guarantee; I don't have to worry</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">*what* the message send returns because I know the other messages I'm</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">cascading go to the original object no matter what.</DIV></BLOCKQUOTE><BLOCKQUOTE type="cite"><BR class="khtml-block-placeholder"></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If you need guarantees than a strongly typed language is better.</DIV><DIV>Why not having guarantees on types etc ... ?</DIV><DIV>A working test is enough of a guarantee. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Usually you don't worry about that </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>10 :append 10 </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>fails, is it ?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Why you worry that this could fail...</DIV><DIV>collection add:1 | add: 1 | add:1</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>We got tests to take care of those problems.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Smalltalk-80 is Smalltalk-80, with all it's libraries and design decisions.</DIV><DIV>And that is fine. Cascade won't go away from there.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>But in a new Smalltalk ? would you keep it ? is there any reason </DIV><DIV>we NEED the ";" operator ? or is just because it's now common use ...</DIV><DIV> </DIV><DIV>We do need the pipe, IMHO, for functional compositions.</DIV><DIV>We do need the cascade operator ... for ... for what ? </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Not to break libraries and to have a cross vendor smalltalk ... is ok.</DIV><DIV>then for what... I can't cover all cases of the cascade operator but something </DIV><DIV>tells me that I might be able to reproduce the work ";" just be using ... an implied protocol.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>like ...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>collection add:1; add:1; add:1; yourself.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>well just say .. "in a new hypothetical ST we do it this way ..."</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>collection add:1 | add: 1 | add:1</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>and overall the "|" could do the same thing and that other cases could be covered with another desing</DIV><DIV>that would be extremely clean anyway.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Your aggressive language comes off as blame, etc.<SPAN class="Apple-converted-space"> </SPAN>And please stop</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">saying "the cascade operator sucks".<SPAN class="Apple-converted-space"> </SPAN></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Fair enough. I'll be more careful. But, if we where talking face to face you would see</DIV><DIV>a smile on my face not an ... aggressive face.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>"The cascade operator sucks" ... ops... :o)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Joking. I apologize to everybody for my language. </DIV><DIV>Let me re-frase: if we would design today a NEW Smalltalk, the cascade operator might be an </DIV><DIV>argument of discussion.</DIV><BR><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">It's pure opinion and utterly</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">irrelevant to the discussion of whether or not<SPAN class="Apple-converted-space"> </SPAN>we need a "pipe"</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">statement delimiter.</FONT></P> </BLOCKQUOTE><BR></DIV><DIV>I tried to motivate quite a lot my opinion. </DIV><DIV>I might say from my point of view it's pure opinion wether you NEED or not a "cascade" statement delimiter.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I might even get convinced otherwise with some examples ... !!!</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR class="khtml-block-placeholder"></DIV></SPAN><DIV><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></DIV></BODY></HTML>