Radical suggestions

Stefan Matthias Aust sma at netsurf.de
Sat Jul 17 11:08:09 UTC 1999


>1: Hierarchical Packages, each offering a distinct Namespace

I agree that packages/modules/name spaces (call them as you like) are
really important.  Having said that, I'd like to mention that Java, the
operation system, has no name spaces.  Just Java, the programming language,
has them.  It's the javac compiler which deals with short names and fully
qualified names (FQN).  On lower levels (aka byte code) there are FQN only
and packages are used for determination of class and method visibilty only.
 But let's ignore visibility for now as this is a different topic.

The whole trick is to define names for global objects.  Names the user (and
sometimes even the application if it uses meta-programming technics) can
use to identify an object.  Smalltalk itself would continue to work even
without a single name (well, as long as no meta-programming, for example
compiling, is not involved)

Of course, there could be more than one name per object.  What shouldn't
happen is that there's just one name for more than one object.
Hierarchical naming structures help here as they reduce the change of
picking the same name twice.  Sun's convention, to use a reversed internet
domain name works quite well (with the exception of what to do if you don't
own a domain name or what if your domain name contains a "-") but actually
any kind of global registry would work.

Even better would be if user could dynamically change names as a last
resort.  This would also help in situations like the package name change of
swing, something along the lines:

import com.sun.java.awt.swing.* as swing.*;

would allow programmers to rename packages for their own code.  Changing
this line to

import javax.swing.* as swing.*;

would have helped then.  I think, Modula2 first showed this mechanism.

Now people could refer to the class com.sun.java.awt.swing.UIButton as
simple swing.UIButton and also ambiguous classes like java.awt.List und
java.sql.List (I think) could be solved IMHO better by keeping a short
package name like

import java.sql.List as sql.List;

That this would conflict with resolving FQN for inner classes is a
different topic and not my problem :-)

For Smalltalk, things are really easy:  A FQN could be simply a squence of
unary messages send to some well known object ("self" for example ;-).
"self smalltalk ui Button" is a reference to a special button class.
"smalltalk" could be implemented in Object, returning a name space name
space object which has a method "ui" which answers another name space
object which has a method "Button" which finally answers a class object.

Actually this could also be a shortcut for

(((Namespace at: #smalltalk) at: #ui) at: #Button)

or for

(Smalltalk atPath: #(ui Button))

depending on the implementation.  Even  "smalltalk.ui.Button" could be
used. Now the compiler would have to detect that an identifier contains
dots, break up the path and do the appropriate steps resolving the reference.

For each class, we'd need to define in which name space it is.  IMHO that's
too fine grained and could be ambiguous as a class could sit in more than
one name space.  I'd prefer if each class would know its module object
(which is unique) and the module knows about imports and aliases.

Each class has a name in its module name space.  Of course objects from
that name space can also registered globally.  The module defines also
imports which are implemented as additional entries in its own module name
space then.

>Now, I would like to extend this idea further: method names should _also_
>be declared within packages!

That's really difficult to define in its semantics IMHO (not talking about
the implementation here).  Example:

module A:  
  extends Object with method x  (FQN = A.x)
  defines class S which calls A.x.
module B:
  extends Object with method x  (FQN = B.x)
  defines class T which calls some method of imported A.S that calls x.

which x is called and why?


>2: A Hierarchical 'File System' within Squeak
>=============================================

Actually I see no difference in hierarchical name spaces and an
image-internal "file system". Perhaps name space is the wrong name and it
should be called object registry so similar.  Even concepts like current
directory and links (hard and soft) can be transfered.  The current
directory a reference to the modules name space, hard links define
shortcuts to other objects while soft links could refer to external objects.

>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. 

Yes.  This would greately improve plugability.  Let's assume you use a
smalltalk system that features a class Dialog that provides some very basic
support for file requesters.  Now you what to provide a better - protocol
compatible - implementation that should be usable without modifying
existing code.  Especially if you want to provide this component to
customers where you cannot assume anything about their configuration.

This kind of service registry would be a big help (as long as you don't
consider modifying the registry as a system modification :-)


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.





More information about the Squeak-dev mailing list