[squeak-dev] On class/metaclass coupling
Michael van der Gulik
mikevdg at gmail.com
Wed Dec 9 20:36:49 UTC 2009
On Wed, Dec 9, 2009 at 12:49 AM, Igor Stasenko <siguctua at gmail.com> wrote:
> For people who think that we should not revise the class/metaclass
> coupling in Squeak,
> just ignore this topic and consider it as a rant :)
> For those, who interested why i think its not a perfect from
> object-oriented point of view, continue reading.
> Ok. Lets start from basics.
> A classes, in smalltalk is a first class objects, which one of its
> strong sides, comparing to other languages.
> Since each object has a class, we also need an object which reflecting
> the class itself, and hence the metaclass.
> But then, each class could have as many instances as it likes to, isnt?
> But here the contradiction, which drives me nuts, when i looking at
> Metaclass definition - 'thisClass' ivar.
> This implies that any metaclass could have only a single instance - class.
> "The receiver can only have one instance. Create it or complain that
> one already exists."
> thisClass class ~~ self
> ifTrue: [^thisClass := self basicNew]
> ifFalse: [self error: 'A Metaclass should only have one instance!']
> but hey..
> what you suppose to do with things like:
> SomeClass clone
That should probably fail. Instead, use >>copy, which (I suspect)
makes a new instance of Metaclass as well.
> I am trying to understand, why do we need this inconsistency by
> enforcing such a rigid rule.
> Like, how often you may need to determine a 'sole' instance of the
> class, or all instances?
> And why it needs to be so fast by keeping a direct reference to it?
> System browser could live well without it.
> Altering the metaclass definition? Well, iterate over all instances
> indiscriminately - using same mechanism as usual class doing for own
> So, it is strange to me, why do we need such tight coupling..
> Is anyone having insights about it?
I'm interested in this because I'll be refactoring Class and Metaclass
soon (next year) for SecureSqueak. I've already got my own
Class/Metaclass hierarchies with no connections to the
SystemDictionary, which allows me to experiment without breaking
The only requirement for a class by the VM is that instance variable 1
is another valid class (the superclass), instance variable 2 is a
valid method dictionary and instance variable 3 is a special "format"
integer. Otherwise you can add whatever you want; every other variable
is optional. You can make your own classes which have no name,
environment, pools and so forth - you'd just break the tools that
As for the tight coupling between class and metaclass, I guess it is
pragmatic. There's no real reason to separate them. If you want a
class with different instance-side methods but exactly the same
class-side methods as another class, then you'd use inheritance.
Because of the tight coupling, the instance variables in a Class or
Metaclass instance could be in either; it makes no difference.
More information about the Squeak-dev