[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.
>
> Metaclass>>new
>        "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
> instances.
> 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
things.

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
inspect them.

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.

Gulik.

-- 
http://gulik.pbwiki.com/



More information about the Squeak-dev mailing list