2009/12/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 2009/12/8 Ralph Johnson <johnson at cs.uiuc.edu>:
>> If you haven't done this already, you should look up Actalk, which was
>> a version of Smalltalk that let you have many classes with the same
>> metaclass.
>>
>> http://map.squeak.org/package/19ae332d-1111-4131-8b56-1fd7e9d2b35f
>>
>> I never used Actalk, I just read the papers.  It was an interesting
>> and worthwhile experiment, but I wasn't convinced that the change was
>> worthwhile.  But perhaps we just need to figure out more to do with
>> it.
>>
>> What you are saying is a little different.  You are just complaining
>> about hardcoding the assumption that each clas has a unique metaclass.
>>  All you are really asking is to get rid of the "thisClass" variable.
>> I don't see any harm in that.  I bet that "new" is rarely called more
>> than once on any metaclass, and that one time is during the creation
>> of the class/metaclass pair.  The bigger issue is that when you
>> evaluate and print the expression "Object class", what happens is that
>> it computes the metaclass and then asks the metaclass to print itself,
>> which it does by fetching the name of its sole instance and appending
>> " class" to it.  In other words, a metaclass does not have a name, but
>> derives its name from the name of its sole instance.  But this doesn't
>> have to be fast, either.  You could call allInstances to find out the
>> instance and get its name.  My guess is that it would hardly be
>> noticeable.
>>
>
> My own guess is that there would be a noticeable down speed in code
> management tools (Monticello & al).
>
> Nicolas
>

Posted too fast...
Beside, if it has several instances, then why insisting on giving a
name related to a specific instance ?

Nicolas

>> Making this change would not cause metaclasses to have more than one
>> instance, but would make it easier for people to change things so it
>> would.
>>
>> -Ralph
>>
>>
>