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
|