I think my intuitive decomposition of classes and modules may be
similar
to others', so let me toss it out.
A class primarily declares a number of instance variables, and holds a number of methods, and can be instantiated. It can also define variables in a local scope, but that's secondary and not even
necessary
if we have modules.
You've described a constructor, not a class.
Does a constructor include a specific definition of instance variable layouts, and a specific set of methods?
A module primarily defines variables in a local scope. Theoretically, it could have instance variables, could have methods, and could even allow instantiation. These abilities are not only secondary, but
might
not be necessary at all.
You've described a namespace, not a module.
A namespace is one of the most important parts of a module. Another important part is dependency information, which normally wouldn't be included in an individual class (you could, but it would seem like quite a burden!). What aspect of modules have I left out, that you consider important?
Overall, these descriptions seemed pretty obvious to me. If you are using different terminology, that would probably explain a lot of the apparent disagreement in the modules discussions here.
-Lex
Here are some more [deep] questions...
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"?
====
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.
====
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?
What is the distinction between an "interface", a "class", 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.
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".
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.
-- Dave S. [SmallScript Corp]
SmallScript for the AOS & .NET Platforms David.Simmons@SmallScript.com | http://www.smallscript.org
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Lex Spoon Sent: Wednesday, February 27, 2002 7:10 AM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Modules and class... [ a off-topic question ?]
I think my intuitive decomposition of classes and modules may be
similar
to others', so let me toss it out.
A class primarily declares a number of instance variables, and
holds a
number of methods, and can be instantiated. It can also define variables in a local scope, but that's secondary and not even
necessary
if we have modules.
You've described a constructor, not a class.
Does a constructor include a specific definition of instance variable layouts, and a specific set of methods?
A module primarily defines variables in a local scope.
Theoretically,
it could have instance variables, could have methods, and could
even
allow instantiation. These abilities are not only secondary, but
might
not be necessary at all.
You've described a namespace, not a module.
A namespace is one of the most important parts of a module. Another important part is dependency information, which normally wouldn't be included in an individual class (you could, but it would seem like
quite
a burden!). What aspect of modules have I left out, that you consider important?
Overall, these descriptions seemed pretty obvious to me. If you are using different terminology, that would probably explain a lot of the apparent disagreement in the modules discussions here.
-Lex
On Wed, 27 Feb 2002, David Simmons wrote:
[snip]
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.
[snip]
Not dipping too deeply into the debate, I still wish to ask: Doesn't this rule out prototype (or even wackier) object systems? Purity of OO and *systmaticisty* of OO and *consistency* of the OO are not *exactly* congruent (and its not clear that these all have inherent or strong value).
Or, so it would seem! To me at least.
Cheers, Bijan Parsia.
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Bijan Parsia Sent: Wednesday, February 27, 2002 7:38 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Modules and class... [ a off-topic question ?]
On Wed, 27 Feb 2002, David Simmons wrote:
[snip]
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.
[snip]
Not dipping too deeply into the debate, I still wish to ask: Doesn't
this
rule out prototype (or even wackier) object systems? Purity of OO and *systmaticisty* of OO and *consistency* of the OO are not *exactly* congruent (and its not clear that these all have inherent or strong value).
Absolutely true. They are not necessarily congruent. However, they are also not "class" based OO systems. Therefore, they introduce other notions like "traits" in the case of "SELF".
There are deeper principles regarding unification and synergy within a meta-system, that I am slowly building up to. However, to do so requires that we first establish some common ground; frames of reference and understanding.
The two leading/premier pure OO (reflective and dynamic) architectures are in Smalltalk and in the CLOS meta-object protocol systems. Among many non-mainstream works, there has also been some very important mainstream work done in various systems at Apple through the 90's, and in architectures like the Sun JDK and Microsoft's COM and .NET platform.
So the conversation needs to start somewhere to identify and build on first principles. We also need understand/agree-on the scope of the problem that is actually being addressed.
Specifically, the scope of the modularization and componentization problem that today's software engineering solutions require, and the challenges faced in just in time integration of heterogonous systems.
-- Dave S. [www.smallscript.org]
Or, so it would seem! To me at least.
Cheers, Bijan Parsia.
Sigh. My own hasty writing typos are bad enough. But when Outlook steps in and helps me it seems to be worse.
I.e., what is a "heterogonous" system :)
It should have read "heterogeneous system".
-- Dave S. [SmallScript Corp]
SmallScript for the AOS & .NET Platforms David.Simmons@SmallScript.com | http://www.smallscript.org
-----Original Message----- From: David Simmons [mailto:David.Simmons@smallscript.com] Sent: Wednesday, February 27, 2002 8:08 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Modules and class... [ a off-topic question ?]
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org
[mailto:squeak-dev-
admin@lists.squeakfoundation.org] On Behalf Of Bijan Parsia Sent: Wednesday, February 27, 2002 7:38 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Modules and class... [ a off-topic question ?]
On Wed, 27 Feb 2002, David Simmons wrote:
[snip]
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.
[snip]
Not dipping too deeply into the debate, I still wish to ask: Doesn't
this
rule out prototype (or even wackier) object systems? Purity of OO
and
*systmaticisty* of OO and *consistency* of the OO are not *exactly* congruent (and its not clear that these all have inherent or strong value).
Absolutely true. They are not necessarily congruent. However, they are also not "class" based OO systems. Therefore, they introduce other notions like "traits" in the case of "SELF".
There are deeper principles regarding unification and synergy within a meta-system, that I am slowly building up to. However, to do so
requires
that we first establish some common ground; frames of reference and understanding.
The two leading/premier pure OO (reflective and dynamic) architectures are in Smalltalk and in the CLOS meta-object protocol systems. Among many non-mainstream works, there has also been some very important mainstream work done in various systems at Apple through the 90's, and in architectures like the Sun JDK and Microsoft's COM and .NET
platform.
So the conversation needs to start somewhere to identify and build on first principles. We also need understand/agree-on the scope of the problem that is actually being addressed.
Specifically, the scope of the modularization and componentization problem that today's software engineering solutions require, and the challenges faced in just in time integration of heterogonous systems.
-- Dave S. [www.smallscript.org]
Or, so it would seem! To me at least.
Cheers, Bijan Parsia.
squeak-dev@lists.squeakfoundation.org
-
Bijan Parsia -
David Simmons -
Lex Spoon