I agree (also with what Randal said). I view myself as someone who uses functional paradigms quite often, but Smalltalk is not a functional language. It's a beautiful blend of pure OO and higher order programming. Just as a solution would look different in Haskell then e.g. Lisp, it will look different in Smalltalk too.
On 8/27/07, Ron Teitelbaum Ron@usmedrec.com wrote:
Hi Randal,
Thanks for the suggestion.
To be clear, even though I support using the symbol ';;' as pipe operator IF we put it in, I doubt I would actually ever use it. I prefer parenthesis, and agree that if you are many levels nested you probably need to ether create more objects to model your complicated behavior, or you need to add temps to make it easier to read your code.
On the other hand I find the cascade extremely useful, especially for creation methods. I find chaining more tolerable when the object doesn't change. It just makes more sense. For the same reason I usually look at long chained methods as an indication that the code is probably written on the wrong class and needs to be cleaned up.
Ron
-----Original Message----- From: Randal L. Schwartz
Would any of the "pipe" advocates mind taking a stab at the *current* source methods, and rewrite the method showing how pipe syntax would have simplified or clarified the method?
I ask this because I suspect that if you're following good practices (such as those adovocated in Beck's "Smalltalk Best Practice Patterns"), you won't actually *need* a pipe syntax, because your code would never have gotten that complicated.
So, instead of writing Smalltalk with a bias for your previous programming language where pipe makes more sense, how about taking some *native* Smalltalk to show how pipe would have helped?
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!