> Here are some more [deep] questions...

Deep indeed!  I've thought about them quite a lot, though, so my
conclusions aren't changed by thinking them through again.  While I
don't have time to get too deeply into this discusison, I can share what
thoughts I've already had on them.



> Does a class define a type (or not)?
> 
> What is "type"? 
> 
> How is "structure" distinguished from "behavior"?
> 
> Are they one and the same thing w.r.t. a "type" or a
> "class-specification"?


Classes might or might not define a type, depending on what kind of type
we are talking about.  (I've rewritten this sentence a few times.  It's
a big discussion -- really, a family of discussions, depending on what
you fill in for the "depending on" clause back there!)

A class does define a structure and a behavior--in fact, that's seems to
be the heart of what a class is.  Structure is about static arrangement
of data, and behavior is about dynamic happenings, but beyond that these
words seem to bend for whatever conversation is at hand.

A specification of something, including a class is some means of naming
a particular instance.  Often, a simple name is used.  A definition of a
class would give enough information to uniquely determine the class.  A
"class specification" might be the same as a "definition of a class".


> ====
> 
> Does a class define a namespace (or not)?
> 
> If not, then how does one specify what namespace scope(s)/things a
> classes methods, or its instances method, can access?
> 
> Where are those (namespace elements) things defined?
> 
> How does one meta-object protocol extensibility for supporting different
> types of "namespaces"? 
> 
> I.e., if the answer is not in classes then the design is the result of
> not thinking in pure OO terms and reflection/meta-object protocol.
> 

Well, today, classes define a namespace with class variables, and they
*specify* some other namespaces which methods will, by default, have
access to.  I don't know where instance variables fit into this; there
is a namespace of instance variables for each class, but that seems a
little different than all the other namespaces being talked about.

I don't think the namespace stuff is a core property of classes, though.
 It's open to design.  You can just as well say that each class
automamtically has its own namespace, and delegate it all to the
namespace concept.  Or, you can say classes *don't* define namespaces,
but only import them.  I'm okay with that, considering that the majority
of classes define no class variables, and in fact that many class
variables could be left at module scope, anyway.  You could even say
that classes don't mention namespaces at all, and that they must import
everything from their surrounding module.  That seems fine, too. 
Overall, the presence of modules seems to offload a lot of the stuff
that has accrued in classes, and to give us some nice design options.


Extensibility leaves me cold.  I'd like to figure out *one* system of
classs, modules, namespaces, etc., before worrying about how to let
programmers develop other ones.  For production applications, it even
seems like a bad idea to define new kinds of namespaces.  It in fact
such a practice would even seem non-OO: OO design is centered around
class (and interface) definitions, not language redefinitions.

OO guys don't go to the drawing board and say "for this project, we
could redefine global variables to work like this".  They say "for this
project, it makes sense to define Thingwitches and Frobnikas".  This is
Smalltalk, not Lisp, and in fact I'm starting to think a pervasive
difference between the two language families is that Smalltalk picks
some specific program organizations that work well, while Lisp leaves
extremely basic things open to design.  ie, in Smalltalk freedom comes
from form, while in Lisp freedom comes from freedom.



> ====
> 
> Does a module specify ownership (or not)? 
> 
> Is a module fundamentally a unit of packaging and deployment (or not)?
> 
> Is "namespace" a role/protocol/behavior/interface/api, or an object
> type?
> 

A module probably has some ownership with it.  A module is surely a unit
of packaging and deployment -- and it's a heavy constraint!

A namespace isn't necessarily any of the things in this list -- it
simply includes a list of names.  We can add more stuff to namespaces if
we want, though.



> What is the distinction between an "interface", a "class", a "behavior"?

An interface is an abstract notion of the way an object will respond to
certain methods.  Interfaces are probably the first cut at how real
programmers think about types in OO programs, and thus they tend to end
up in a lot of OO type systems (OO type systems without interfaces, and
without something to replace them, tell you something about the designer
of that type system!)

I don't know why we are talking about them in this discussion, though --
Smalltalk doesn't have interfaces in the language.

Behavior and interface do have some similarity.  Perhaps behavior tends
to be more specific, and interface more abstract; but a very precise
interface would seem to actually be a behavior.


> 
> When you think about these ideas in terms of specific objects (or
> classes) of objects, you're not thinking in OO terms. Behavior (the
> message semantics an object understands/responds-to) are all that
> matters here. 

*Boggle*.  I don't know what "here" is, and I don't see how behavior is
all that matters for *anything* that has shown up in this discussion.


> We can formalize these into "interfaces" (or protocol api's if you
> like). Any object which supports a given interface/protocol should be
> able to perform in the "role" defined by that "interface/protocol".

Yes, but where are the interfaces?  This is Smalltalk.  Interfaces are
abstract, not a language feature, and that's a good thing -- OO type
systems are either experimental, bad, or not automatically checkable. 
(I'm leaning more and more toward the opinion that types should be left
for proof asssistants, and that trying to make them automatic is
weakening the meaning of types so much that they aren't very useful.) 
To give an idea of the difficulties, note that in the wild interfaces
tend to come in gradations: some objects have at:, at:put:, and keys,
while others have the full Dictionary protocol.  Some streams are
readable, writable, and re-positionable, in any combination.  Some have
binary versus ascii mode.  A readable, re-positionable stream is
automatically peek-able, but some streams are peek-able even without
being re-positionable.  It's quite a morass, if you try to support the
classes people write when they are unrestricted!

Perhaps, instead of interfaces, you are talking about something like
mixins?  Or perhaps you have some stripped down notion of interface that
is both useful and possible to implement?  Do tell!


> In considering these design issues it is important to view the system
> from the meta-object protocol level, not the object-procotol level. 
> 
> I.e., think in terms of the object-model as defined by the meta-system.
> Where we are describing/talking-about the structure of the meta-system
> and its facilities.
> 

Again, I'm left boggled.  While I have my own mysticisms, it will take
more than keywords for me to understand someone else's.  Plain old logic
and debate, though, I can handle.


Okay.  After this whirlwind tour, here's a summary on the question that
spurred it off:

	classes: behavior, structure, namespace, maybe types, interfaces
(though normally not in the program code)

	modules: ownership, namespace


Are these really the same type of thing?  They only overlap at
namespaces.


-Lex