From: David Simmons <david.simmons@...>
Date: 2001-11-27T17:08:09+09:00
Subject: [ruby-talk:26631] Re: Selector Namespaces: A Standard Feature for Smalltalk?


"Panu Viljamaa" <panu@fcc.net> wrote in message
news:3C032A26.C695771D@fcc.net...
> Ok. So if I understand this correctly, selector namespaces mean that:
>
> We can add or modify a method in an existing class but have the change
affect only selected parts of the
> system - because a given method can have several implementations that
co-exist simultaneously and get
> used in different parts of the system.  Thus: " '50' asMoney"  could cause
the execution of different
> implementations of #asMoney, depending on where the method call appears.

The "co-exist simultaneously" phrase is only true within the envy
repository. They cannot co-exist in an executable image; and if they could,
there are no Smalltalk language facilities for expressing/deciding which one
of the methods to execute.

>
> I believe this has been a feature of  VisualAge Smalltalk for a long time
already ("Extended classes").
> Right ? Making it standard would be cool naturally, if it can be done
simply.

----
I assume you are referring to Envy Class Extensions and Application
Partitioning of a Class?

If so, then it would be correct to say that the envy project management
[modularization] objectives are very similar to those provided in the
SmallScript module system, but the envy runtime/deployment capabilities do
not provide any of the features of the SmallScript selector namespace
system.

In Envy, class-extensions belong to an Application (project). A
class-extension is a set of "delta's" that should be applied to a class
[which is external to the Application (project)] when the producing a
runnable image for that Application. This concept is (from a static
viewpoint) identical to the SmallScript notion of "modules" which own
[contain] changes to classes.

But, that is all you get in the envy system. Which means that if you want to
build an image composed from two applications which both define #foo on
<Object> you cannot do so, because one of those two definitions would have
to get stomped on. Instead, you must rename one of the methods. Which allows
one to have a design time solution if you have all the conflicting elements
in hand; but does not provide for an equivalent
runtime/just-in-time-deployment solution.

I.e., the envy management system is perfectly capable of keeping each
version packaged in the repository with its application.

1. But when it comes to deployment, classic Smalltalk runtimes are not
capable of having two different versions of a method with the same name in
the same class.

2. And, if they were (which can be hacked in), classic Smalltalk runtimes do
not have any facilities for expressing which one of those versions should be
invoked from a given callsite (message-send).

It is these latter items that I first build into QKS Smalltalk
[SmalltalkAgents] in 1996 and which I significantly refined for unification
and performance in the from-scratch design of SmallScript in 1999.

Features 1&2 are what "selector namespaces" enable in a basically
transparent fashion.
----

VisualAge Smalltalk does not support selector namespaces nor does it have
the ability to perform scoped method binding; and I'm pretty darn certain
that this has never been a feature of VisualAge Smalltalk.

-- Dave S. [www.smallscript.org]

>
> -Panu Viljamaa
>