panu wrote:
>
> There is a simple workaround for class-namespaces that
> works in *every* Smalltalk (and in [explitive deleted -ed] too).
> Before complicating things further by adding explicit class-
> namespace support to a language, consider using this
> design pattern:
>
> 1. Create all your classes with a suffix.
> For example I could create a new class
> called 'TransformerPANU'. It is unlikely
> that anyone would come up with the same
> name in their designs.
>
> 2. Create a method named #Transformer in your
> class(es) or superclass as:
>
> Transformer
> ^TransformerPANU
>
> 3. In your code, instead of accessing the global
> 'TransformerPANU' directly, call:
>
> self Transformer.
>...
====


A better pattern for this is as follows.

(1) Same as above
(2) Create methods in referring class(es):

category: 'accessing class'
>>transformer
^self class transformer

category: 'collaborators'
class>>transformer
^TransformerPANU

(3) In your code, always refer to
transformer via the local method

(self transformer) selectorWhatever


---
Advantages: Encapsulates further, as client
doesn't need to know the class
side methods, and referenced object
can switch between local supplied
(instance side answers inst var)
and externally supplied
(instance side forwards to class)
without changing all the
sendersOf:

Subclasses can each independently
choose whether to override with
a locally supplied or an
externally supplied object.

Scanning the class side methods
of a class quickly informs developers
of collaborating classes, especially
useful when subclassing, copying,
or porting a class.

====
An alternate form of this pattern is:

(2') Create a mapping subclass of Object
named the same as your suffix
(in your case it would be
PANU>>
).

For each of your classNameWithSUFFIX classes,
create a mapping method:

PANU>>transformer
^TransformerPANU

and in referring classes create
this collaborator method instead:

class>>transformer
^PANU transformer

---
Advantages: Entire "extension package"
is mapped -- the mapping class
shows which classes are in the
"extension package", even when
the "extension package" is a
set of file-outs or a set
of some other deploymentForm.

Especially useful in environments
with external CMS (CVS etc).

====
Regards,

-cstb