2009/12/9 Michael van der Gulik <mikevdg at gmail.com>:
> 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.
>
Good to know. SystemDictionary should die. Theory of Relativity is
something we should learn from :)
Universe has no central point. Every point in Universe is its center.

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

Yes. And i'm always thinking towards making things less heavyweight,
and keep only required minimal in class/behavior protocols that tools
should know about, instead of thousands and thousands of methods
implying tight coupling.

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

A single class denotes a family of objects, which can be instantiated
and have same behavior.
Inheritance creates a different family of objects by specialization.

The main problem with inheritance is that it doesn't solves any
problems, it only inheriting them.

Imagine a locomotive with bunch of wagons tied to id. The more wagons
you adding, the slower it become, no matter how powerful it was
initially.
What you proposing is adding another wagon to the train and expect
that it will run faster.


> Because of the tight coupling, the instance variables in a Class or
> Metaclass instance could be in either; it makes no difference.
>

Not sure i understood, what instance variables you talking about.
Any instance of class keeps reference back to a class through implicit
class slot in object header.
But class doesn't sees all of its instances directly, because its impractical.

Still, there is a protocol that supports an idea of having a way to
'see' all its instances (allInstancesDo:).
But to my thinking, this is an over-engineered stuff. Such kind of
reflection useful purely for mutating instances (after modifying the
class definition),
but its too slow and fragile to be used for any real-time tasks, since
it implies a linear scan of all objects in object memory. But new
objects could be created at any moment, a process which scans the heap
can be interrupted.. there are too much issues preventing this feature
to work fine. Unless you register every created instance in some sort
of collection and keep it in class's own ivar :)

Conserning instances mutation:
You, as a designer of secure-squeak, should know well about
problematics of class modification (especially mutation of its
instances). It should be prohibited. Instead, one should create a
modified copy, but never replace the old class by modified one and
never attempt to mutate exising instances.. otherwise you will be
unable to contaminate the numerous security problems.

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


-- 
Best regards,
Igor Stasenko AKA sig.