Radical suggestions

Christian Brunschen cb at df.lth.se
Thu Jul 15 08:17:57 UTC 1999


Hi all,

There appears to be much discussion going on about the Squeak image,
code / project division, etc. I am by no means an expert in these matters,
but I won't let that stop me from airing a few ideas that might make
things a bit more manageable.

1: Hierarchical Packages, each offering a distinct Namespace
============================================================
This is one of the things I like most about Java: knowing that, as long as
I stay within my own package hierarchy, I can name my classes anything I
want; there will be no collisions with pre-existing classes. 
This also means that I can mix-and-match packages from different vendors,
without having to worry about any side effects because both packages
happen to define a class with the same name.

Now, I would like to extend this idea further: method names should _also_
be declared within packages! This way, I woldn't even have to worry about
additions made to existing classes, beause even if two different packages
wanted to add a method 'foo' to Dictionary, these would in fact be two
distinct 'foo' methods, and no clash would occur.


2: A Hierarchical 'File System' within Squeak
=============================================
One of the nice things about, say, Unix systems, is that there are
well-defined places in the file system where you can find certain files -
or in the more general case, _objects_, such as devices. 

A similar system in Squeak, where there would be, say, a hierarchical
Directory structure which would contain named references to objects
(either Classes or Instances), would make it possible to assign names
within the directory structure to certain objects, which could then be
referenced by those names.

So? Well, this would separate implementation of the objects in question
from how they would be found. In combination with packages as mentioned
above, this would offer a powerful environment:

Say that we specify that a certain service - 'Foo' - be available,
implemented by an arbitrary class. A reference to this class would be
placed ad '/Services/Foo' in the object system. 

Now, anyone could write a class, with an arbitrary name and
implementation, and place a reference to that class at '/Services/Foo'.
The class referenced by that name might be replaced, at some time, by one
from another developer entirely.

And while all this was going on, all other code in the system could just
relax and call upon "the class at /Services/Foo" when they required the
service 'Foo'.

This concept can be even further refined, along the lines of 'search
paths' for objects; something simple yet powerful, not unlike what Apple
are using in Mac OS X, might be useful: named resources (applications,
libraries, etc) are sought, in order:
  * Below the User's home directory
  * In the hierarchy for items installed locally on this machine
  * In the hierarchy for items installed shared on a network of machines
  * In the system hierarchy
This allows system administrators and users tocustomize their environment
without having to alter the system itself; any changes and additions can
easily be located and, if need be, removed.

Smalltalk already has an inkling of this, which could probably be used as
a starting point - as the 'root' of this 'object system' if nothing else.

A system such as this would also pave the way for a 'multi-user Squeak',
where several different people could work independantly within the same
Squeak image, at different time, or possibly even simultaneously, if such
support were added to Squeak. 



Yes, I know that these changes all make Squeak more of an Operating System
than just a programming environment - but Squeak already offers its own
windowing system, so I don't really feel I'm trying to take Squeak in a
direction it's not already going,at least somewhat. Of course, if I am
mistaken, then please correct me.

I also know that none of the ideas above are especially revolutionary -
and that is one of the reasons why I think they migh be able to fly; the
things I suggest above have been tested in some fashion in other systems
and found to be useful and workable. I'm 'just' trying to create a synergy
to create something even better in the form of the resulting combination.


Best regards

// Christian Brunschen





More information about the Squeak-dev mailing list