Peter -

>I am looking at a new Squeak 2.7 image with all the 2.8 updates filed in. 
>
>I am wondering what the "purpose" of the ProtoObject is? 
>
>It's now the parent class of Object.
>nil subclass ProtoObject subclass Object ...
>
>It's not documented in the "comment" for the class.

Shame on us.

>My guess is that it's some sort of preparation for a "persistence storage
>system"?

Here's the answer in the form of a class comment...

ProtoObject establishes minimal behavior required of any object in Squeak, even objects that should balk at normal object behavior.  Generally these are proxy objects designed to read themselves in from the disk, or to perform some wrapper behavior, before responding to a message.  Current examples are ObjectOut and ImageSegmentRootStub, and one could argue that ObjectTracer should also inherit from this class.

So, as you can see, it is more than just preparation, but you have the right idea.

	- Dan
-------------------------
Here's some more background...

On 11/21/99, I put out a request ("Let's Get Bizzy"):
>>We have several subclasses of nil already, with a few more waiting 
>>in the wings.  While instances of these classes must not respond to 
>>normal messages, things are much more convenient if they do have a 
>>small kernel of methods to support generic object maintenance.  So 
>>this project is to make such a class, slip it into the class 
>>hierarchy above Object (will require some pointer surgery (and don't 
>>forget to re-route Object class's superclass pointer)), and 
>>incorporate the methods in that are now in all the other subclasses 
>>of nil.  It would also be nice to include or point to summary 
>>explanations of doesNotUnderstand:, cannotInterpret:, and any other 
>>related mechanisms.  This is actually simple, but it has to be done 
>>right.

Marcus Denker signed up, and his implementation became part of the system about a week later.

Also, I should include a message that Dave Smith sent me on the same topic...

>Dan:
>
>I played with this in IBM Smalltalk once, though I never attempted to 
>insert it above Object where it belongs. I wanted a base class from 
>which I could build objects (like monitors) which did not need to 
>inherit a huge number of methods.
>
>After playing with it a bit, I ended up with two classes:
>
>    RootObject
>       BasicObject
>
>RootObject was a 'subclass' of nil. Its protocol was minimal, 
>basically handling all those things which are required to be an 
>object. These are mainly messages sent by the virtual machine, 
>messages send my the handlers of those, perform, and equality and 
>identity testing. I had 21 methods there.
>
>BasicObject was an object sufficient for the debugger to run on its 
>instances. It had 36 methods.
>
>I wrote it, add subclasses for synchronized objects (only one user at 
>a time), and subclass of that which implemented monitors. It then got 
>shelved to do something some one else wanted and there it sits.
>
>Anyhow, breaking the class into two classes seemed cleaner, and 
>allows more flexibility later.
>
>Dave