<< Back to previous view

[CLJS-439] IEncodeClojure only works on same-context Objects Created: 11/Dec/12  Updated: 27/Jul/13  Resolved: 20/Jan/13

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Tom Jack Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

The default impl uses (identical? (type x) js/Object), but objects created in another JS context (e.g. another frame) will fail this test, since their constructor is a different js/Object. Thus js->clj is the identity on such objects.

I wonder if there are any related problems anywhere else, e.g. with protocols? This seems to be the only occurrence of js/Object.

Maybe this can be fixed by extending IEncodeClojure to object? I don't immediately see how to do that without incurring the option destructuring overhead recursively.



 Comments   
Comment by David Nolen [ 13/Dec/12 7:55 AM ]

I don't think this is something that ClojureScript should try to address at all. To me it seems similar to various classloader issues in JVM land.

Comment by Tom Jack [ 15/Dec/12 2:31 AM ]

OK, I don't disagree.

Comment by Sean Grove [ 17/Dec/12 12:33 AM ]

This is causing some unpleasantness, and I'm not aware of the classloader issues. Why check (identical? js/object x) instead of (goog.isObject x) on https://github.com/clojure/clojurescript/blob/master/src/cljs/cljs/core.cljs#L6948 ?

Comment by Chris Granger [ 17/Dec/12 1:26 AM ]

this bit me as well and I can't see a downside to using goog.isObject. I agree with David about not going down a rabbit hole here, but I think we can do the "right thing" for free.

EDIT: I spoke too soon. Looks like native objects, like dom nodes would blow up in this scenario. Also, goog.isObject returns true on functions, but that would be easy enough to deal with.

Comment by Tom Jack [ 17/Dec/12 2:31 AM ]

I suppose extending to object would similarly cause trouble for dom nodes etc?

If you can get ahold of the js/Object from another frame, is it possible to extend IEncodeClojure to it?

Comment by David Nolen [ 21/Dec/12 5:50 PM ]

I have some experience with this stuff - it's a rabbit hole. There are many objects that can cross contexts for which we can provide no sensible equality guarantees. If you need to move data between JS contexts then use GClosure and stick to the basic JS data types. I'm inclined to close this one unless someone has a brilliant comprehensive solution that I'm not seeing right now.

Comment by David Nolen [ 20/Jan/13 12:52 AM ]

This one is tricky. Closing for now.

Generated at Mon Sep 01 23:29:03 CDT 2014 using JIRA 4.4#649-r158309.