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