For this Smalltalker, I don't start with a functional approach, I
start with an object-oriented approach. Compared to functional, I have
lots of state (class names and instance variables).

To the extent that I program functionally, it is usually inside of a
method (eliminating temps). When I show this style to Java programmers
(or use this style on a Java project), it is not well received. So I
assign to temps and stay away from parens and chains (or pipes). I
believe Joe Winchester calls this debugger friendly coding.

asPipe appeals to me because it doesn't change the syntax of the
language. This Smalltalker takes pride in having a tiny core language
that has remained mostly unchanged. I doubt I would be confused about
asPipe cascades because I would see the receiver is the pipe object.
This also makes it easier to port (as long as your dialect doesn't
already have an asPipe implementation).

I would like to use asPipe in my own code (just did the equivalent of
an asPipe reject:;reject:;select: with parenthesis). If the syntax
changed version were adopted for Squeak, I might use it if I wasn't
concerned about ports to other Smalltalks.



On 8/28/07, Fabio Filasieno <fabio.filasieno at gmail.com> wrote:
>
>
> On Aug 28, 2007, at 12:30 AM, Bert Freudenberg wrote:
>
>
>
>
>
> With the generic pipe object from my change-set in the original thread this
> gets you both - no need to define new methods:
>
>
>
>
>    highestNumberedChangeSet
>
>        "ChangeSorter highestNumberedChangeSet"
>
>        ^self allChangeSetNames asPipe
>
>            select:[:aString | aString startsWithDigit];
>
>            collect:[:aString | aString initialIntegerOrNil];
>
>            ifNotEmpty:[:list | list max]
>
>
> I have to admit that the asPipe idea is really cool and it might do the
> trick.
>
> A minor minor thing: you still need to explain it, and it's better to have 1
> syntax token attached to 1 meaning.
> Is a bit ugly that cascade changes it's meaning: sometimes does X, some
> times does Y.
>
> Still the asPipe is a very very nice hack.
>
> I think the question is different from adding or not syntax to do a trick.
>
> Do Small-talkers want to assert:
>
> "Use functional programming when possible"
>
> or not ?
>
>
> This is question. And I can't answer that.
>
> It's not :
> "Shall we add a new syntax token to do the trick ?"
>
> Fabio FIlasieno
>
> PS. Note that I associate functional programming with a chained application
> of functions (better if pure)
>
>
>
>
>