Domaining using classes.

Klaus D. Witzel klaus.witzel at cobss.com
Sat Aug 12 02:58:19 UTC 2006


On Sat, 12 Aug 2006 03:41:17 +0200, Michael van der Gulik wrote:
> Klaus D. Witzel wrote:
>> Hi Michael,
>>  on Tue, 08 Aug 2006 11:19:37 +0200, you wrote:
>>  Klaus D. Witzel wrote:
>> That's the easy part: clones of classes share their method dictionary  
>> (in  form of a pointer, not as a copy). Only the class pointer of per  
>> domain  created instances is changed, nothing more and nothing else. A  
>> very good  ROI, that is :)
>
> ....wow. That is thinking outside the square. I had never considered  
> stripping a thin layer off Class/Metaclass like that.
>
> So, a concrete example is needed. Say I have a class "Person". Then,  
> normally:
>
> alice := Person new.
> bob := Person new.
>
> In a domained image, say I have two domains, alicesDomain ("ad") and  
> bobsDomain ("bd"). Now:
>
> adPerson = Person class copy new. " adPerson is a Class "
> "<<Do class initialisation and stuff here, copying stuff from Person>>"
> adPerson methodDict: Person methodDict.
> adPerson domain: alicesDomain. " Sets an instance variable in the Class"
>
> bdPerson = Person class copy new.
> "<<Do class initialisation here>>"
> bdPerson methodDict: Person methodDict.
> bdPerson domain: bobsDomain.

Take care when uttering #copy in the presence of a class (e.g. a behavior)  
and/or #new in the presence of a metaclass. I would'nt even whisper such  
words when a class is around; classes/behavior have (too) tight a relation  
with ClassBuilder and comrades, so I tend to think of it as #copy being  
reserved for exclusive use by that comradeship.

I always use #clone for classes (after checking with the implementors of  
#clone in the releases of Squeak, of course).

> Now we can do:
> alice := adPerson new.
> bob := bdPerson new.

   8-)

> In other words, each domain has its own set of classes, but each class  
> shares its instance variables (methodDict, instanceVariables,  
> superclass, format etc) with other classes of the same... er... class.

Yes, and it would be sufficient to just clone the fields superclass,  
methodDict and format (like in an instance of Behavior). This is all that  
the VM needs. I have direct subclasses of Behavior in my projects, see  
attached example on negotiable interfaces. Message category  
'*required-by-my-users' keeps users of direct subclasses of Behavior not  
bark so loud.

> I could probably cludge up some Namespacing or other magic to get  
> "Person" to resolve to the domain's local version of the Person class,  
> so you don't need to use "adPerson" and "bdPerson" but just "Person".
>
> So now, finding the domain of any given object would be easy:
>
> Object>>domain
> 	^ self class domain.
>
> Trivial!

   ;)

> Disadvantages:
> - umm... well its a bit hard to implement, but no less so than any other  
> ways of doing this.

Yes, I think so, too.

> So who takes the credit for this? Alexandre Bergel and Klaus Witzel?

Alex was the first person that I met who understood what I was talking  
about. So yes, it was invented by the two of us.

/Klaus

> Michael.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NegotiableInterface.st
Type: application/octet-stream
Size: 16451 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060812/47fd57ff/NegotiableInterface.obj


More information about the Squeak-dev mailing list