ClojureScript

A named fn shadows `js/fn-name`

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Declined
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

Description

The function

(fn console [] js/console)

will return a reference to itself when called.
This happens because the function is transpiled to

(function console(){return console;})

Solution proposals

Mangle internal function names like let bindings

The internal name of a generated js function should be treated like a let binding, hence gensymed.
Thus the function would be transpiled to something like

(function console_1337(){return console;})

References

Brought up in https://groups.google.com/d/msg/clojure/QZmGrjNVurs/NxFtq8yDCFIJ

Activity

Hide
Herwig Hochleitner added a comment -

Attached test uses js/eval, because that's one of the shortest global identifiers, that should be available on every js runtime.

Show
Herwig Hochleitner added a comment - Attached test uses js/eval, because that's one of the shortest global identifiers, that should be available on every js runtime.
Hide
Herwig Hochleitner added a comment -

As detailed in the ML thread, CLJS-680 introduced :js-globals in an attempt to fix this issue. :js-globals should be removed along with a proper fix.

Show
Herwig Hochleitner added a comment - As detailed in the ML thread, CLJS-680 introduced :js-globals in an attempt to fix this issue. :js-globals should be removed along with a proper fix.
Hide
David Nolen added a comment -

We're not going to do this. If anything we're going to move towards more stable names - it is a requirement if we ever want to achieve CLJS step debugging via remote debugging protocols.

Show
David Nolen added a comment - We're not going to do this. If anything we're going to move towards more stable names - it is a requirement if we ever want to achieve CLJS step debugging via remote debugging protocols.
Hide
Herwig Hochleitner added a comment -

The reason for closing this seems bogus to me: There will always be some amount of lexical name mangling in clojurescript, because otherwise some code will miscompile (see CLJS-401). Therefore any hypothetical step debugger must already have some sort of source mapping information from the compiler. Why should more mangling do any more harm then?

I say: Just gensym each and every single lexical binding and be done with it forever. JS names are not meant to directly correspond to CLJS names.

Show
Herwig Hochleitner added a comment - The reason for closing this seems bogus to me: There will always be some amount of lexical name mangling in clojurescript, because otherwise some code will miscompile (see CLJS-401). Therefore any hypothetical step debugger must already have some sort of source mapping information from the compiler. Why should more mangling do any more harm then? I say: Just gensym each and every single lexical binding and be done with it forever. JS names are not meant to directly correspond to CLJS names.
Hide
David Nolen added a comment -

That "there will be some amount of lexical name mangling" is about as problematic as there will be "some inaccuracy to source mapping". Let's wait and see. Until then we prioritize stable names from source produced by the compiler.

One interesting line of thought is to eliminate gensym'ing altogether and instead use a source map like approach for generating stable names where every symbol is instead uniquely identifiable by namespace index N, and line N, column N.

Show
David Nolen added a comment - That "there will be some amount of lexical name mangling" is about as problematic as there will be "some inaccuracy to source mapping". Let's wait and see. Until then we prioritize stable names from source produced by the compiler. One interesting line of thought is to eliminate gensym'ing altogether and instead use a source map like approach for generating stable names where every symbol is instead uniquely identifiable by namespace index N, and line N, column N.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: