Tracing proxies

I just committed a change to Kernel to the Inbox which simply moves
messages in the 'tracing' category from Object to ProtoObject.  I know
we want to keep ProtoObject to an absolute minimum, but I also think
it is useful to be able to trace connectivity to proxies.  I would
also like to move Object>>#isLiteral up to ProtoObject to support
tracing, but refrained for now until I can gauge whether there is
support or opposition to this idea.  Thanks.

 - Chris

On Mon, 23 May 2011, Chris Muller wrote:

> I just committed a change to Kernel to the Inbox which simply moves
> messages in the 'tracing' category from Object to ProtoObject.  I know
> we want to keep ProtoObject to an absolute minimum, but I also think
> it is useful to be able to trace connectivity to proxies.  I would
> also like to move Object>>#isLiteral up to ProtoObject to support
> tracing, but refrained for now until I can gauge whether there is
> support or opposition to this idea.  Thanks.

IMHO #chasePointers and #explorePointers should be moved to the Tools
package. The rest can be moved to ProtoObject, but it's unnecessary.
Proxy implementations should use Igor's stratified proxies
(http://code.google.com/p/pharo/issues/detail?id=3648 ) instead of
subclassing ProtoObject. IMHO we should integrated them to Squeak.


Levente

>
> - Chris
>
>

> IMHO #chasePointers and #explorePointers should be moved to the Tools
> package. The rest can be moved to ProtoObject, ...

Ok, I'll do that sometime soon.

> ... but it's unnecessary. Proxy
> implementations should use Igor's stratified proxies
> (http://code.google.com/p/pharo/issues/detail?id=3648 ) instead of
> subclassing ProtoObject. IMHO we should integrated them to Squeak.

I don't know what a "stratified" proxy is, but a brief look at that
code looks very interesting!  So, by nil'ing out the methodDictionary,
it ensures that object gets first chance to "handle" every message,
even if it is already implemented in Object.

If so, that's very nicely elegant.  At first, I was hoping this
approach would allow Magma a chance to handle the problem of passing a
proxy to a primitive, rather than the user having to send a #yourself,
but it doesn't look like it would help for that.

Is there any practical advantage to stratified proxies over standard
proxies which inherit from ProtoObject, or is it just more elegant?

thanks..

On Thu, 26 May 2011, Chris Muller wrote:

Right.

>
> If so, that's very nicely elegant.  At first, I was hoping this
> approach would allow Magma a chance to handle the problem of passing a
> proxy to a primitive, rather than the user having to send a #yourself,
> but it doesn't look like it would help for that.

If we add this package to the Trunk, then we will be able to identify
these kind of proxies in the arguments of primitive calls when they fail
and retry the primitive with the real objects. This should help in most
cases.

>
> Is there any practical advantage to stratified proxies over standard
> proxies which inherit from ProtoObject, or is it just more elegant?

Yes, by using these proxies we can remove methods which don't have to be
understood by all objects from ProtoObject.


Levente

>
> thanks..
>
>

>> If so, that's very nicely elegant.  At first, I was hoping this
>> approach would allow Magma a chance to handle the problem of passing a
>> proxy to a primitive, rather than the user having to send a #yourself,
>> but it doesn't look like it would help for that.
>
> If we add this package to the Trunk, then we will be able to identify these
> kind of proxies in the arguments of primitive calls when they fail and retry
> the primitive with the real objects. This should help in most cases.

I'm not opposed to adding this package to trunk, but I guess we could
do that even if we didn't add it trunk by sending #yourself couldn't
we?  For example, for Object>>#perform:

perform: aSymbol
        "Send the unary selector, aSymbol, to the receiver.
        Fail if the number of arguments expected by the selector is not zero.
        Primitive. Optional. See Object documentation whatIsAPrimitive."

        <primitive: 83>
        ^ self perform: aSymbol yourself withArguments: (Array new: 0)

Would would the solution look like (approximately) using
stratified-proxys approach?  I thought this is nice because it doesn't
necessarily assume the primitive failed because aSymbol was a proxy..

Whatever the solution, I am ready to do something soon; I have several
#yourself sends sprinkled throughout my code to avoid the situation,
which is annoying.

On Thu, 26 May 2011, Chris Muller wrote:
This wouldn't work, because either not all primitives work with proxies
(not all of them send #yourself), or there will be infinite recursion if
the primitive keeps failing (e.g. the argument is nil).

>
> Would would the solution look like (approximately) using
> stratified-proxys approach?  I thought this is nice because it doesn't
> necessarily assume the primitive failed because aSymbol was a proxy..

Let's say we have a MutatingProxy class (a subclass of
MessageCatchingProxy) and all mutating proxies are subinstances of this
class. This way all mutating proxies have something common we can check.
Since the #class method won't be a real message send, therefore something
like the following will work for all primitives:

perform: aSymbol

  <primitive: 83>
  (aSymbol class inheritsFrom: MutatingProxy) ifTrue: [
  ^self perform: aSymbol someMethodThatReturnsTheRealObject ].
  self primitiveFail


Levente

>
> Whatever the solution, I am ready to do something soon; I have several
> #yourself sends sprinkled throughout my code to avoid the situation,
> which is annoying.
>