Re: Name spaces in Dolphin...

[Peter van Rooijen]

"panu" <panu@fcc.net_NOSPAM> wrote in message
news:F4SdnQa3lfBEezSiRVn-gQ@fcc.net...
> Blair McGlashan wrote:
>
> > I'm afraid there is a downside, and it is incompatibility. There is no
one
> > standard namespace system, in fact they are all different, and often not
> > just in the detail. ...
>
> There is a simple workaround for class-namespaces that
> works in *every* Smalltalk (and in Java too). Before
> complicating things further by adding explicit class-
> namespace support to a language, consider using this
> design pattern:

[snip description of pattern]

> This has the added benefit (over plain namespaces)
> that you now *encapsulate* the information of which
> actual object will be returned by #Transformer!

Great and important benefit!

> Using a method-call in this manner leads to more
> cohesive, flexible, reusable code than accessing
> a global directly (in several places). Remember
> the Trick-of-63: Globals are BAD.

Yes, but you can do even better.

> The downside is that 'self Transformer' is slightly
> longer than plain 'Transformer', but that's the
> price you pay for better encapsulation, and for
> keeping the language & code simple and compatible
> with other dialects.

Just put it in a class variable named 'Transformer' (same class where you
would have put the #Transformer method) and get all the benefits without any
of the downsides. Smalltalk in fact /does/ have a standard namespace system
in the form of class variables (okay, it's broken in Squeak, but it works
fine in Dolphin and the main other dialects).

Cheers,

Peter

P.S. I'm trying to point out something that might be helpful. I hope to
avoid coming across as an 'insufferable pedant' or some such :-)))).

[cstb]

panu wrote:
>
> cstb wrote:
>
> > So the trace is
^^^^^

Panu,


I meant this to indicate that what followed (further down)
was a trace, rather than source code; hoping you'd read it
similar to tracing an algebra problem like this:


4 * x + 4 = 2
4 * x = -2
x = -1/2


> > (self transformer) selector
> > --> (self class transformer) selector
> > --> ActualReceiver selector
> >


but I think you took it as something else entirely.
Sorry - poor description on my part.


> What I'm proposing is to always access a global
> or class (for instance NeededClass below)
> with something like:
>
> self NeededClass
> ...more steps snipped...

> The point being that the most important / valuable
> step is the first one. I don't go into detail
> of what *should* happen inside 'self NeededClass'.


We're talking past each other, I think.

I'll be trying (below) to repair the disconnect,
so others may want to take this as a
yet-another-pedantic-bore
warning, and bail now...


====

> Using 'whichClassToUse' inside it may indeed
^^^^^^^^^^^^^^^^^

This is a mis-interpretation, I think.
Let's replace the mistaken word and
keep going:


> Using inside it may indeed be
'some specific code'

> the best solution, but I allow the situation and
> circumstance affect that decision. In effect I
> encapsulate this decision inside my (i.e. self's)
> method #NeededClass.


Right - we're agreeing up to this point.


> In Smalltalk, the SystemDictionary 'Smalltalk' is the
> 'holder of globals'. In fact the compiler gets the
> classes from it - but with no regards to encapsulation.


Yes.


> Therefore in many cases I've written:
>
> self NeededClass
> --> self Smalltalk NeededClass
>
> The above I think follows your pattern closely:
> Delegate to an object responsible for knowing
> the thing asked for, but do the delegation by
> accessing the delegate via a further message-send.


No - although the *contents* of the pattern
can be read that way, the *intent* of the
pattern is something else, and the intent
isn't carried through in your example.


Delegate to an object responsible for knowing
the thing asked for.

Yes.

Now an important distinction -
if the thing being asked for is
*not* a collaborating class,
doing as you describe is fine;

but - if the thing being asked for
is a collaborating class, the pattern is:
use (as a delegate) another class, which is
either a) my own class
or b) a superclass of my class.
Such that you

... do the delegation by accessing
the delegate
via a further message send...
*to myself*,
with then an indirection
to get from myself
to the actual Delegate's method.

If you use this pattern *all the time*,
then you get the {very desireable} results
I described in the previous post.

Therefore, where our (separate) discussion
of namespaces needed to refer to a collaborator,
I injected the above pattern into the discussion,
because I *always* use this when collaborators are
involved, regardless of whatever else is going on.

Perhaps unfortunately, the details of this pattern
interfered with the description of the patterns we
were actually discussing.

====

And here I'll admit that I don't know whether it is fair
to refer to the above as a pattern, it might be an idiom,
and hence off topic for half the distribution.
I can't decide, so I left the distribution alone.

====

Now, quite apart from all the above,
I'll add that your description below,
motivating the idea for namespaces,
is great. Thanks for including it.

Cheers,

-cstb



{I suppose I should sign this one

-yapb
}


----
> Since 'Smalltalk' (The SystemDictionary) above is
> accessed via a method, it is easy to come up with
> the idea that each 'self' may in fact have their
> own SystemDictionary. Then it becomes only natural
> to make the small step of calling such objects
> 'namespaces' instead:
>
> self NeededClass
> --> self namespace NeededClasses.
>
....snip...
>
> - Panu Viljamaa