pipe

Fabio Filasieno fabio.filasieno at gmail.com
Sun Aug 26 10:10:57 UTC 2007


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.

This is my worst frustration too in SmallTalk.

Fabio





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070826/db487477/attachment.htm


More information about the Squeak-dev mailing list