On Aug 27, 2007, at 4:56 PM, Denis Kudriashov wrote:
It's very cool.
Smalltalk is wonderfull language. We can implement any ideas without making changes in language (as Java or C# live).
I think pipes is very usefull in DSL implementation and usage, simpler and fast object inspecting. But long message chaines in domain code are bad smell
Long chains smells alright to me.
A long chain of filters (especially when functions are side-effect free) is
- readable, quickly understandable, self documenting
- easy to write as you compose
- particularly useful in prototyping : simply compose what you have quickly, than, if required, rebuild it properly
Not a code smell to be.
But that code is written by someone who prefers his intent as a composition of simpler parts, particularly when code is side-effect free.
But ... it might NOT be good for production for performance reasons or because some re-factoring could make it even more clear in certain cases.
On Aug 27, 2007, at 7:15 AM, Jason Johnson wrote:
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.
Happy to see that it seems that your opinion has changed on point 1 from the beginning of the thread, and mine has changed on point 2.
And to close this issue: the pipe idea come to me in the beginning as a pipe vs cascade problem, as the cascade didn't allow the functional compositions I care of. So I presented it that way to the list (happily making some noise), but it's obvious now that I'm not selling anymore a "dump-the-cascade-idea""