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@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)