Hi all! :-)

When we were fiddling around with some proxy implementations today, Marcel and I discovered an interesting set of issues regarding ProtoObjects.

Let's start with a concrete bug:


Code to reproduce <do it>:

ProtoObject new class.


Expected behavior:

DNU exception, because #class is implemented on Object only.


Actual behavior:

Outputs ProtoObject.

Even stranger: If you debug the method instead and simulate the #class send, you get a "simulated message class not understood" error.

If you subclass ProtoObject and override/forward #class, the results will deviate based on whether you are debugging or executing the code.


Some thoughts:

There are two options: Either to implement #class on ProtoObject (by moving the primitive definition up from Object), or to remove it from the specialObjectsArray so that a send to #class is not compiled differently than a send to any other regular message.


This leads us to the rather general question: What special messages should an instance of ProtoObject understand?

We don't answer this question completely consistent at the moment: For example, #instVarAt: is implemented on Object, but #instVarsInclude: is implemented on ProtoObject. Again, it is a bit weird that the implementation of #instVarsInclude: calls #class which is implemented on Object only. And so it goes on:

  *   #someObject is implemented on Object, but #nextObject is available in ProtoObject.
  *   #withArgs:executeMethod: is implemented on ProtoObject, whereas #perform:withArguments: is on Object.
  *   #ifNotNil: is implemented on ProtoObject; however, #ifNotNilDo: is implemented on Object. (btw: does the latter still have any raison d'être?)
  *   #flag: exists on ProtoObject, and #yourself exists on Object only. Isn't #yourself rather a syntactical element we would like to behave exactly the same way for every possible message receiver? (btw: Is there a good reason not to speed up #yourself via specialObjectsArray)?
  *   (I don't claim for completeness)

And just some other problems regarding to ProtoObject (just collecting them here instead of forgetting them forever):

  *   ObjectTracer is broken due to several reasons. Will fix this soon.
  *   Inspectors cannot inspect ProtoObjects correctly (for example: Inspector openOn: (ObjectTracer on: Display)). This is because #instVarAt: is implemented on Object only so this message is forwarded.
Maybe we should replace these critical calls from Inspector by something like #tryPrimitive:173withArgs:? But should we do so in Inspector or rather in a new subclass named ProtoInspector or similar? Hm, then we would need to implement #inspectorClass on ProtoObject, which is bad either ... We will keep investigating this issue.

However, the crucial question is: What special messages should an instance of ProtoObject understand? On the one hand, the idea of ProtoObjects is to work as total proxies with a maximum amount of forwarding potential, which implies a minimum number of methods. On the other hand, certain aspects such as accessing instvars or executing messages are really identity-related. Looking forward to your comments :-)

Best,
Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200214/b0b9a289/attachment.html>