Re: [ooc-compiler] libadt: Naming Issues

[Stewart G. <gre...@mu...>]

Michael van Acken wrote:
> 
> I'm trying to come up with a sensible naming scheme for modules that
> are incorporated into the "new" ADT library.  My ad-hoc approach to
> this problem goes like this:
> 
> o All modules of this library use the prefix `ADT:'. Test modules are
>   not considered part of the library.  They reside in the top-level
>   namespace, have `Test' as prefix, and are not installed together
>   with the library modules.
> 
> o New datatypes are defined in `ADT:*' modules, as long as they are of
>   a ``general purpose'' nature.  Specialized versions use the name of
>   the more general implementation as prefix. Example:
> 
>     ADT:Dictionary
> 
>         The general purpose implementation of a dictionary. It relies
>         on objects defining the ADT:Object.Object.HashCode and
>         ADT:Object.Object.Equals method.
> 
>     ADT:Dictionary:AddressKey
> 
>         A streamlined version of a dictionary that uses the object's
>         address as key, instead of relying on its hash method. This
>         version is basically useless if there are objects that are
>         considered equal even if they do not have the same address
>         (like strings).
> 
>         The user is encouraged to give such modules a more sensible
>         name on import, for example
>           `IMPORT Dictionary := ADT:Dictionary:AddressKey'.
> 
>     ADT:Dictionary:AddressKey:IntValue
> 
>         An even more specialized version of ADT:Dictionary:AddressKey,
>         that maps object addresses to LONGINT values.
> 
>         Again, the user is encouraged to give such modules a more
>         sensible name on import, for example
>           `IMPORT Dictionary := ADT:Dictionary:AddressKey:IntValue'.
> 
> o Modules providing implementations, services, or algorithms for data
>   types, but do not define a new data type themselves, use the same of
>   the base module as prefix. For example, a serialization implementation
>   is in module ADT:Object:Storage, because it implements the abstract
>   rider interface defined in ADT:Object.
> 
> Is this sensible enough to make it an official policy?

I think this would probably work. Here are some additional thoughts...

As far as I can see, there are two choices for subdivision:

- Implementation: sub-module provides implementation of abstract type,
or refines an existing implemntation.

- Specialisation: sub-module extends a type with additional
functionality.

In some situations one or both may be necessary, so its probably
important to understand the system so that one can "locate" the relevant
library code (ie. if it is "ad-hoc", it must be consistent).

An example:

java.util.Map defines an abstract type (interface) for mapping keys to
values.

java.util.HashMap extends java.util.AbstractMap to implement the Map
type, but other classes outside java.util also implement Map (eg.
java.awt.RenderingHints, java.util.jar.Attributes). These (obviously)
cannot be considered sub-modules.

java.util.SortedMap defines an extension (sub-interface) of Map, in
which the natural ordering of keys is preserved. java.util.TreeMap
extends java.util.AbstractMap to impelement SortedMap.

Using a structured module naming, one might try:

ADT:Map
ADT:Map:HashMap           (impelemntation)
ADT:Map:SortedMap         (sub-interface)
ADT:Map:SortedMap:TreeMap (implementation)

Alternatively (using only implementation), we might have:

ADT:Map
ADT:Map:HashMap
ADT:SortedMap
ADT:SortedMap:TreeMap

(any others?)

The Java framework doesn't attempt to do anything like this. The scheme
fails when data-types implement more than one interface. This may not be
such a problem for Oberon-2 which only allows single-inheritance.
However, it may be clearer to present these sorts of relationships in
the documentation (especially if eg. an ADT data type is implemented
outside the ADT package). This could be generated automatically (eg. via
oocn) without any possibility of accidental "misplacement".

Certainly, at the package level the name-space concept is very useful
(eg. to prevent name-clashes between modules in "Core", "ADT", ... or
for structuring large programs).

I guess the other question would be: can ADT be adequately structured
without multiple interfaces? In Java, classes like HashMap implement
several interfaces: Map, Serializable and Clonable. In addition, there
are interfaces implied by the fact that all classes sub-class Object
(eg. finalisation, comparability, hashability, synchronisation,
conversion to string representation).

We can get around the problem by defining an extensive base class for
all objects. The problem is that some methods may then become
"optional", as they won't be supportable for all data types. It is also
rather inflexible, as functionality can't be added in an independent
way.

Personally, I'd like to see some sort of structural sub-typing based on
sets of  interfaces. There's a good discussion of this here:

  http://www.abo.fi/~mbuechi/publications/OOPSLA98.html

Unfortunately, I don't think any languages currently implement this sort
of thing. Perhaps it could be a candidate for inclusion in Oberon-3 ;-)

Cheers,
  Stewart