Object: Identity vs. Environment

Andreas Raab andreas.raab at gmx.de
Wed May 28 06:17:35 UTC 2003


Hi Joel,

> From:
> http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_prin
> ciples_behind_smalltalk.html
> 
> "Modularity: No component in a complex system should depend 
> on the internal
> details of any other component. "
> 
> In this case, my take on it is: global methods don't scale 
> and result in interdependencies (or at least make it so likely
> that it's inevitable).

You're seeing the term _way_ too static here. A "function" really is some
portion of code that's bound by a "name" and how this name is resolved is an
entirely different matter. In fact, one can argue that methods are nothing
but "name to function mappings" and in the same sense environments can
include different name to function mappings.

> In the croquet doc:
> http://glab.cs.uni-magdeburg.de/~croquet/downloads/Croquet0.1.pdf
> 
> "This means that a user only has to think of one syntax-semantic
> relationship. *Receiver message* means *the meaning is in the receiver*"
> (*'s around italics)
> 
> In the example of #isFoo, following the above guideline would 
> certainly preclude #isFoo being placed on Object.

No, quite to the contrary. It merely means that all objects are capable of
responding to #isFoo without having to make specific assumptions about the
kind of object. In other words, putting the method #isFoo into Object
_enables_ us to put the true meaning into the receiver rather than having to
make assumptions about the kind of object we're dealing with.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list