build option: exported function naming conversion convention #320

Closed
andrewdeandrade opened this Issue Jun 27, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@andrewdeandrade

In clojurescript (as in clojure and other lisps), it's common to name a function using kebab-case. This however is not a valid function name in javascript (unless it's a method on an object and you only access it via bracket notation). Currently, the compiler, when a function is exported with a kebab-cased name like is-list, the resulting JavaScript code is snake_cased to is_list instead of camelCased as isList. This doesn't follow standard JavaScript camelCase function naming conventions as is used in ECMA-262 and almost everywhere else in the JavaScript ecosystem.

(def ^:export is-list cljs.core/list?)

(from https://github.com/swannodette/mori/blob/master/src/mori.cljs#L123)

Can we get a build option that turns on automatic conversion of function names to the de facto standard of camelCase?

related: swannodette/mori#81

@cemerick

This comment has been minimized.

Show comment Hide comment
@cemerick

cemerick Jun 27, 2014

Collaborator

Exported names are 100% up to the author; people can write (def ^:export isList ...) at will, and the ClojureScript compiler will not muck with that name. If someone is interested in following JavaScript conventions, they can do so, just like they do (or, don't) when writing JavaScript directly.

In any case, this is would be a ClojureScript compiler issue, if anything. lein-cljsbuild is merely a convenient Leiningen interface. I seriously doubt an option will ever be provided to change how ClojureScript names are mangled to JavaScript, though.

Collaborator

cemerick commented Jun 27, 2014

Exported names are 100% up to the author; people can write (def ^:export isList ...) at will, and the ClojureScript compiler will not muck with that name. If someone is interested in following JavaScript conventions, they can do so, just like they do (or, don't) when writing JavaScript directly.

In any case, this is would be a ClojureScript compiler issue, if anything. lein-cljsbuild is merely a convenient Leiningen interface. I seriously doubt an option will ever be provided to change how ClojureScript names are mangled to JavaScript, though.

@cemerick cemerick closed this Jun 27, 2014

@andrewdeandrade

This comment has been minimized.

Show comment Hide comment
@andrewdeandrade

andrewdeandrade Jun 27, 2014

"I seriously doubt an option will ever be provided to change how ClojureScript names are mangled to JavaScript, though."

why?

If a tool is built to export to another language, it's not unreasonable to expect that care should be taken to default to the conventions of the community of that target language when it is the tool in question is responsible. If the shoe was on the other foot and clojurescript or clojure was the target language, I would imagine that users in this community would expect the same.

That being said, I assumed this was a lein-cljsbuild issue since the this is the interface where build options are defined. Is the mangling of ClojureScript names to JavaScript names not happening here but in leiningen?

"I seriously doubt an option will ever be provided to change how ClojureScript names are mangled to JavaScript, though."

why?

If a tool is built to export to another language, it's not unreasonable to expect that care should be taken to default to the conventions of the community of that target language when it is the tool in question is responsible. If the shoe was on the other foot and clojurescript or clojure was the target language, I would imagine that users in this community would expect the same.

That being said, I assumed this was a lein-cljsbuild issue since the this is the interface where build options are defined. Is the mangling of ClojureScript names to JavaScript names not happening here but in leiningen?

@cemerick

This comment has been minimized.

Show comment Hide comment
@cemerick

cemerick Jun 27, 2014

Collaborator

The name-mangling happens in the ClojureScript compiler.

I personally don't think it's ClojureScript's role to enforce a particular JavaScript naming convention. Totally aside from opinions though, an option like what you propose would make it impossible for ClojureScript codebase A to reliably e.g. call exported functions defined in ClojureScript codebase B, without coordination about the name-mangling mode used when B was compiled.

Collaborator

cemerick commented Jun 27, 2014

The name-mangling happens in the ClojureScript compiler.

I personally don't think it's ClojureScript's role to enforce a particular JavaScript naming convention. Totally aside from opinions though, an option like what you propose would make it impossible for ClojureScript codebase A to reliably e.g. call exported functions defined in ClojureScript codebase B, without coordination about the name-mangling mode used when B was compiled.

@andrewdeandrade

This comment has been minimized.

Show comment Hide comment
@andrewdeandrade

andrewdeandrade Jun 27, 2014

"I personally don't think it's ClojureScript's role to enforce a particular JavaScript naming convention."

Totally agree. It's just that the default used is kind of anti-social. I want to use mori and I'm playing around with it, but upon casually sharing it with others, the gut reaction, as stupid as it may be is "ewww"

I'm a fan of ClojureScript, it's one of the few compile-to-JS languages that legitimately contributes ideas to the JavaScript ecosystem (as opposed to CoffeeScript, which was mostly a way for rubyists to avoid JavaScript's C syntax and have more ruby syntax, which is an aesthetic feature than functional feature like S-expressions provide). With that in mind, ClojureScript libraries, like mori, that introduce these great ideas and ways of working with them would see greater adoption if they didn't pop up with a default syntax that breaks convention of the consuming community.

"ClojureScript codebase A to reliably e.g. call exported functions defined in ClojureScript codebase B, without coordination about the name-mangling mode used when B was compiled."

Then don't make it an option then. Make it the only way in a future version. :) Developers who want to keep their existing JS api can change the exported values to be explicitly snake_case or can do the better thing and change their API to conform to JavaScript community conventions.

Anyways, totally respect your decision to close this down and move on, but this would be a nice default to change, since it will impact the APIs of future libraries written with ClojureScript by people who never spent time coding in JavaScript and therefore never learn that community's norms.

"I personally don't think it's ClojureScript's role to enforce a particular JavaScript naming convention."

Totally agree. It's just that the default used is kind of anti-social. I want to use mori and I'm playing around with it, but upon casually sharing it with others, the gut reaction, as stupid as it may be is "ewww"

I'm a fan of ClojureScript, it's one of the few compile-to-JS languages that legitimately contributes ideas to the JavaScript ecosystem (as opposed to CoffeeScript, which was mostly a way for rubyists to avoid JavaScript's C syntax and have more ruby syntax, which is an aesthetic feature than functional feature like S-expressions provide). With that in mind, ClojureScript libraries, like mori, that introduce these great ideas and ways of working with them would see greater adoption if they didn't pop up with a default syntax that breaks convention of the consuming community.

"ClojureScript codebase A to reliably e.g. call exported functions defined in ClojureScript codebase B, without coordination about the name-mangling mode used when B was compiled."

Then don't make it an option then. Make it the only way in a future version. :) Developers who want to keep their existing JS api can change the exported values to be explicitly snake_case or can do the better thing and change their API to conform to JavaScript community conventions.

Anyways, totally respect your decision to close this down and move on, but this would be a nice default to change, since it will impact the APIs of future libraries written with ClojureScript by people who never spent time coding in JavaScript and therefore never learn that community's norms.

@cemerick

This comment has been minimized.

Show comment Hide comment
@cemerick

cemerick Jun 28, 2014

Collaborator
Anyways, totally respect your decision to close this down and move on

To be super-clear, lein-cljsbuild has no role in defining the behaviour of the ClojureScript compiler; it simply provides a convenient way to invoke it via Leiningen.

Collaborator

cemerick commented Jun 28, 2014

Anyways, totally respect your decision to close this down and move on

To be super-clear, lein-cljsbuild has no role in defining the behaviour of the ClojureScript compiler; it simply provides a convenient way to invoke it via Leiningen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment