On 8/26/07, Fabio Filasieno fabio.filasieno@gmail.com wrote:
Duplicate... don't know. I think one temporary variable per activation should be enough, because you can overwrite it.
lol. come on! Personally I weigh making a variable at the same level as making a new method. Sometimes I would choose making the method instead, and this often leads to nice refactorings.
And it's not just a temp variable we are talking about, it's more statements as well. And you still haven't given any reason we need to drop the cascade operator. If you want pipe then make pipe. That has no effect on cascade unless you want the ; character.
I can see that. But ... for example.
collection := OrderedCollection new. collection add:1.
evaluates to one. Why ? Why not to collection ?
As pointed out in another email, because it provides more value/options this way.
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.
Having guarantees is not about strongly/late bound typing. Smalltalk has guarantees, just in a different place then something like Haskell.
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 ...
Yes, for sure I would. There is no other operator that does what it does. I might add a Haskell-style $ operator as well, but that's a different question.
and overall the "|" could do the same thing and that other cases could be covered with another desing that would be extremely clean anyway.
Oh great, so we can redesign half of Smalltalk just so you don't have to type some parenthesis. And the "clean" part is your opinion. I find the cascade very elegant and clean.
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.
Well, that's a fair point. The actual words only count about 10% of actual communication, so it can be very hard to judge someones intentions.
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 ... !!!
Here is the thing: It does not *matter* if we need it or not. You are talking about two seperate issues:
1) We need what you call a "pipe" operator 2) You don't think we need cascade
Point 1 is an easy sell. I don't see why you are strongly for point 2. I like the cascade operator and I find it useful. If you don't, don't use it. You can just make a new operator that does the "pipe".
And another advantage of this is, I think it would be pretty trivial to make the compiler treat everything to the left of a $ (or whatever you choose) as though it were in parenthesis. At that point you would also have the option of actually putting the parens in automatically on fileout, so that you're 100% compatible with all other Smalltalks as well.
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.
But again, we have that right now. This is exactly how Smalltalk works today. The only thing the "pipe" is doing is giving us another way to disambiguate for the parser.
SomeObject beSpecial bePretty beFast doStuff
works in the "pipe" way. You are changing:
(Someclass new name: 'Fred' age: 20) drawOn: someCanvas
into:
Someclass new name: 'Fred' age: 20 | drawOn: someCanvas
This is a little helpful, but not to the point of tossing out something that can't be done otherwise. Especially when the tools help out with adding parenthesis (if you download the dev image you can just select a statement and type ( and it puts the whole thing in parens).
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.
I was talking about the do operator, which makes Haskell look more left to right, though it's still right to left for every statement.