On Aug 26, 2007, at 10:16 AM, danil osipchuk wrote:

I think the subject should not be compared directly with unix pipes.

Unix pipes represent a way to reuse fixed parts of functionality -

compiled programs. These are black boxes. As a result application

logic for a shell script goes directly to the script itself which is

flat.

Smalltalk is very different - you always can add behaviour you
need to the other object and the application logic is distributed
across the system.

That's not the point, but you are right, Unix and Smalltalk are different.

In regard to the black boxes thing.

self is the input of a process which is defined the class of self.

The dispatch system when I do:

obj doSomeStuff

will send obj to a process called doSomeStuff.

self is the input of process.

ps -aux | grep 'fabio' | sort

is like:

Squeak ps: 'aux' | grep: 'fabio' | sort

But this could be more object oriented in the sense that we are not passing

text but objects. It could be better factored.

What objects give you is .... polymorphism.

This way you don't have to write

This is Unix (or C style) style .

MyData_doSomeStuff

MyOtherData_doSomeStuff

MySomeOtherData_doSomeStuff

you need to have a unique identifier for the method.

This is with objects

doSomeStuff defined in MyData

doSomeStuff defined in MyOtherData

doSomeStuff defined in MySomeOtherData

The difference is in text only vs objects, but at the end of the day you have

a process (the method), you have an input(self), you have a return value(well... the ^value :o) ).

I think there are a lot of analogies.

Long chains of unary selectors (analog for the

discussed operator) are often considered as a code smell because this

may put functionality to a wrong place.

It's true but I like it that way when I'm prototyping !!! because I can quickly do

stuff by reusing methods.

For instance, if one sees

something like "self myOrganization hrDivision currentHRManager

suggestApplicant" - he may consider to factor the code fragment to the

hrDivision class.

This is a good example. If and only if you have already there

all the methods you suggested I would do that way the first time. Quick and easy.

Than I would do some testing code. Than I would make it better (factoring) and faster (fixing the algorithm),

making sure that I don't not break the tests.

((thingOne isSuch or: [thingTwo isThat]) and: [thing isNotEmpty]) or:

[self whatever]) ifTrue: [self doSomething] (assuming evaluating

operators don't work here). This example is not concrete of course but

I recall when I was frustrated having to write similar code.