Re: Some questions about GOOPS and CLOS in general

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

Eric Moore <moore@chem.cmu.edu> writes:

> Jost> 1. You say that modules and a type system are two orthogonal
> Jost> concepts.  2. You say that the module handles encapsulation on
> Jost> behalf of the class' objects.  3. You say that a module can
> Jost> contain more than one class.
> 
> Jost> Sorry, but these statements can't go together.
> 
> I dunno about anyone else, but I fail to see why.  Unless you're
> saying that a type system *must* encapsulate all of a classes methods,
> which is in contradiction to 1.  

Yes, a proper type system has to encapsulate all of a classes methods.
But still the type and module systems are two orthogonal concepts.
The module system handles the physical structure and the type
system the logical structure but they *both* provide (more or less)
the same functionality.  

type system                   module system

inheritance                   use a module, syntax:  (use ...)
association ("has a")         access a module, syntax: (access ...)
class                         module
object                        environment
encapsulation (public slot)   encapsulation, syntax: (export ...)
"friend" (as used in c++)     protected export, syntax: (protect ...)

As you can see they provide more or less the same functionality.
But they *do* belong to two diffenend domains.

The "trick" I am proposing is that it is possible to
handle a module as a type of the system:  The module
/is a/ class.  Instead of the module /has a/ class.

If you don't agree that a class should encapsulate all
of its methods and slots think about the difference of
classes and structures:

struct s {                       class s { /* pseudo c++ */
   int a;                           private int a;
   int b;                           public int b;
}                                }


> If you want per-class encapsulation
> then you cannot have multiple classes in a module, however, the
> existance of "protected" "friend" and all the other bizarre stuff 

The "friend" declaration is used because some classes have a
special relationship.  When people work together on a project
they know each other and may want to use features that their
customers should avoid.   In C++ you declare a class as
a "friend" to access its internals.  

But this "friend" declaration is a mis-concept.  When people work
together they use the same physical structure (for example "c" headers etc.).
The module system reflects this structure.  That means that we
can allow all other modules stored in the same package to access
each others private features.

For example:

Module (ice-9 test) is located in the package ice-9 and it can
access the private features of the module (ice-9 boot).


> C++ indicates that this is not always true.  Encapsulation does not
> alays occur along class boundaries.

Can you give me an example of a class that has to access the private
features of another class that was developed independently?  


[Wanted side effects]
> Ok, as an example I'll use a newtonian mechanics (say molecular
> dynamics or planetary motion) simulator.   We will at each time step,
> cause pairs of bodies to interact.  The interactions will be equal and 
> opposite, affect both bodies, and depend on the characteristics of
> both.

Isn't the method that changes these two objects a part of
the class "newton mechanics"?

> (interact a b)

To which class does "interact" belong?

Yes, I know that does neither belong to a, b nor to the container
"newton mechanics".   I consider this a design error.  :)



Jost