Smalltalk › Amber Smalltalk

Problem with Object Comparison

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Gustavo Soto Ridd

Problem with Object Comparison

Hi amber comunnity,

I'm actually working with a graph visualization software that uses object comparison as his main source of relations. But as I've read the documentation, in Amber a JSObjectProxy is instanstiated every time a message is send to a proper JS object, this property makes that a software that runs on Pharo does not work in Amber. Do you know anything about this particular property of non-unique proxy and their comparison?

For a more practical explanation of the problem,, i've tried this code:

person1 := <{name:"John", age:41}>.

person2 := <{name:"Peter", age:15, parent:person1}>.

person1 = person2 parent false

person1 == person2 false

Greetings

Nicolas Petton

Re: Problem with Object Comparison

Hi Gustavo,

The problem is that JSObjectProxy lacks #=

Here's a quick implementation:

= anObject
| proxy |
anObject class == self class ifFalse: [ ^ false ].
proxy := anObject yourself.
<return self._jsObject() == proxy._jsObject()>

Nico

Gustavo Soto Ridd <[hidden email]> writes:

> Hi amber comunnity,
>
> I'm actually working with a graph visualization software that uses object
> comparison as his main source of relations. But as I've read the
> documentation, in Amber a JSObjectProxy is instanstiated every time a
> message is send to a proper JS object, this property makes that a software
> that runs on Pharo does not work in Amber. Do you know anything about this
> particular property of non-unique proxy and their comparison?
>
> For a more practical explanation of the problem,, i've tried this code:
>
> person1 := <{name:"John", age:41}>.
> person2 := <{name:"Peter", age:15, parent:person1}>.
> person1 = person2 parent *false *
> person1 == person2 *false *
>
>
> Greetings

--
Nicolas Petton
http://nicolas-petton.fr

Gustavo Soto Ridd

Re: Problem with Object Comparison

Nico,

I've actually created other solution for the case, is a subclass of JSObjectProxy called UniqueProxy that overrides the #on: message at class methods. This new method creates a new proxy for a particular JS Object and registrates within it so when a second call of #on: to the same JS Object is done, the Proxy is not instanciated again and is returned.

on: aJSObject

| proxy |

proxy := self new

jsObject: aJSObject;

yourself.

if(typeof aJSObject["__VisuProxy"] == "undefined"){

aJSObject["__VisuProxy"] = proxy;

return proxy;

} else {

return aJSObject["__VisuProxy"];

}

I don't know if this is the best solution as it modifies the actual JS objects, but maybe is a good idea if we want to reduce the amount of instanciations at message sending.

Nicolas Petton

Re: Problem with Object Comparison

Indeed, it can be a good idea. I would do that on the level of boot.js
instead, and name the property $smalltalk_proxy (this way it's not a
valid Smalltalk selector).

Nico

Gustavo Soto Ridd <[hidden email]> writes:

> Nico,
>
> I've actually created other solution for the case, is a subclass of
> JSObjectProxy called UniqueProxy that overrides the #on: message at class
> methods. This new method creates a new proxy for a particular JS Object and
> registrates within it so when a second call of #on: to the same JS Object
> is done, the Proxy is not instanciated again and is returned.
>
> on: aJSObject
> | proxy |
> proxy := self new
> jsObject: aJSObject;
> yourself.
> <
> if(typeof aJSObject["__VisuProxy"] == "undefined"){
> aJSObject["__VisuProxy"] = proxy;
> return proxy;
> } else {
> return aJSObject["__VisuProxy"];
> }
>>.
>
> I don't know if this is the best solution as it modifies the actual JS
> objects, but maybe is a good idea if we want to reduce the amount of
> instanciations at message sending.

--
Nicolas Petton
http://nicolas-petton.fr