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 at 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 at 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!
>
>
>
>