ClojureScript

IEncodeClojure only works on same-context Objects

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Declined
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • 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.

Activity

Hide
David Nolen added a comment -

This one is tricky. Closing for now.

Show
David Nolen added a comment - This one is tricky. Closing for now.
Hide
David Nolen added a comment - - edited

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.

Show
David Nolen added a comment - - edited 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.
Hide
Tom Jack added a comment -

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?

Show
Tom Jack added a comment - 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?
Hide
Chris Granger added a comment - - edited

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.

Show
Chris Granger added a comment - - edited 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.
Hide
Sean Grove added a comment -

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 ?

Show
Sean Grove added a comment - 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 ?
Hide
Tom Jack added a comment -

OK, I don't disagree.

Show
Tom Jack added a comment - OK, I don't disagree.
Hide
David Nolen added a comment -

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.

Show
David Nolen added a comment - 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.

People

  • Assignee:
    Unassigned
    Reporter:
    Tom Jack
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: