Packages (Re: Radical suggestions)

Edward P Luwish eluwish at uswest.com
Thu Jul 15 18:51:24 UTC 1999



Les Tyrrell wrote:

> As a practical consideration...
>
> It is possible, and I have seen this happen, for different third party
> code to not only extend existing classes by adding new methods, but
> also to overwrite the same previously existing method.  One can argue

etc.

Here is a possible solution based entirely on my ignorance of the Squeak system and
ignoring all performance/elegance/etc. consequences:

Add a namespace instance variable to Object, defaulting to root (or system or nil,
whatever).

Create a Namespace class that defines, among other things, a hierarchy of
namespaces for the purpose of resolving references to objects created within
different namespaces.  Single inheritance, please!  Of course,
system/root/nil/whatever is at the top of the hierarchy.

Change the message dispatching primitive so that all references to objects
(including methods) will be made within the namespace of the sender (or its
hierarchy of supernamespaces if not found).  This permits the redefinition of a
fundamental method in a base class without disturbing the integrity of the system.
When a sacrosanct (i.e., from Squeak Central) method is executing, since its
namespace is root/system/nil, all the messages it sends will be via other
sacrosanct methods to sacrosanct objects.  This ensures the system will continue to
work even if your project involves changing the order relationships of Integer, as
an extreme example.

Change Project so that the namespace instance variable will be set correctly for
every object defined within the project (including subprojects), and add a
namespace field to any New Project dialogs.  Make sure it (and other dialogs)
complain bitterly if you try to do anything in the root/system/nil namespace other
than create and populate a new subclass, but allow the user to ignore the
complaint.

By copying (or somehow aliasing) an existing class under its own name (but a
different namespace) it is even possible to rearrange the inheritance hierarchy of
fundamental system classes without disturbing the system.

Do you think any of this is possible, feasible, desirable?  It certainly would
cover all the bases mentioned in your last email.

Ed





More information about the Squeak-dev mailing list