Pipe syntax and the current methods
Michael Lucas-Smith
mlucas-smith at cincom.com
Mon Aug 27 19:01:49 UTC 2007
It's not like you even need a new syntax to avoid the paranthesis - just
new kinds of objects, eg:
nonHermsOlderThanTensMothersNames := lotsOfPeople selecting: [:each |
each age > 10]; rejecting: [:each | each sex = #unknown]; collecting:
[:each | each mother]; selecting: [:each | each notNil]; collecting:
[:each | each name]; asOrderedCollection
No new syntax, just new objects. Has this already been covered in the
thread? if so, sorry for bringing it up again.
Michael
Ron Teitelbaum 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!
>>
>
>
>
>
More information about the Squeak-dev
mailing list
|