Better handle object property comparison/equality/identity
If you get a non primitive property it will not be the same object that was set. From @appden :
it would be ideal for objects (i.e. non-primitive values) to survive a roundtrip. Right now the getters look like they always return a new JS object, which will inevitably cause unexpected weirdness in JS code, especially now that we have native Map and Set collections. As long as each object in Realm has a unique identifier, I think this will be relatively easy to achieve
I'm not sure this will be possible to do, but at a minimum it would be nice if == worked for all object types even if === does not.
I'm almost positive there is no way to override == behavior for object comparisons. Do objects inside a Realm have some kind of unique identifier so we could track live objects exposed into a JS context? When I built a JS-ObjC binding, I accomplished this thanks to each object's "unique identifier" being its pointer. :smile:
We discussed last week that this would be possible for objects that have a primary key, since we can use the value of the primary key to track live objects in the JS context. I prototyped this in PR #118, and it works, but doesn't yet support changing the primary key on an object.
I believe this is more than just a "nice to have" since we cannot override == and object hashing like we can in the ObjC and Swift bindings (I know ObjC uses -isEqual, not ==, but that fits with how Cocoa works). Those bindings only support equality for objects with primary keys as well, so I think that a valid enough precedent for the JS binding to work similarly rather than blocking this issue on some future object id support in core.
Adding this would not only benefit us from having a functional == for primary-keyed objects, but would also allow for them to be used with Array.prototype.indexOf (and friends) as well as with Maps and Sets.
We are going to add some kind of unique id in the near future, so we should wait until it has been introduced in core/sync.