Hi Ralph,

on Mon, 21 Aug 2006 14:26:13 +0200, you wrote:

> A BOM is not Type Object.

Not that I wrote that, I wrote: "... most general form ...", which can be  
read as: class "Type Object" inherits from B.O.M. :)

> The point of Type Object is that the
> "type" describes a general category or "type" to which the instance
> belongs.

Sorry, I do not read this kind of magic in the words "Type Object". It can  
be used the way you described, no problem.

> A BOM describes a part-whole relationship. An instance is
> not a part of the type.

Sure, constituents are part of the whole. And instances of your "Type  
Objects" are part of your "instance" objects. Because of N:1, the opposite  
direction would not be possible.

> When I use Type Object in Smalltalk, I like to give the type a #new
> method to create an instance of that type.

You mean like #newTypeObject?

> This helps convince people
> that it is a little like a class.

And I would teach them that #new is inherited from the instance side of  
Behavior and why this is so and what #new is good for in Smalltalk (and  
copycats) and then let them find out that #new is based upon a primitive  
which cannot be overridden.

> But even among Smalltalkers, it is
> useful to have a name for the pattern.

Absolutely. And I agree with you that Type Object is a nice pattern and a  
nice name. My question for Stef was rather about, what is the importance  
of this (almost) unavoidable pattern (which I attempted to generalize a  
bit further) and which he put at the first level towards metamodeling (as  
if metamodeling where a hierachical concept with root "Type Object").

> I've helped several projects
> by naming the pattern that they were already using and thereby helping
> the architect (who already understood the pattern deeply and
> intuitively) communicate with his team.

Yes, communication is good and even better if people mutually understand  
the respective vocabulary.

/Klaus

> -Ralph Johnson
>
>