function naming convention

[andrewdeandrade]

This is a total bikeshedding issue (see Wadler's Law), so feel free to close this, but I was curious why you didn't use standard JavaScript function/method naming conventions with the mori API. I searched the open and closed issues and found nothing.

For example, why mori.is_list instead of mori.isList? It follows neither a normal JavaScript naming convention (camelCase) nor the Clojure function naming convention (kebab-case) (because that syntax would not accessible via dot notation). Is this the result of a default in the clojurescript compiler?

I can't help but imagine the gut reaction my colleagues would have to seeing snake_case appearing over any shared codebase I contribute to. Obviously this isn't going to stop me from experimenting and using mori, because it looks like an excellent library, but it's really funky to have all your code and all your libraries use the same naming conventions as ECMA-262, except for one.

Given that mori.js is transpiled from clojurescript code to JavaScript, I reckon it should be possible to define which naming convention you want used in the generated code. Is this already possible with the clojurescript compiler? I looked at the sample options for lein-cljsbuild and didn't see anything there for defining the naming convention (https://github.com/emezeske/lein-cljsbuild/blob/1.0.3/sample.project.clj)

[aearly]

Haha, +1 for the bikeshedding issue. Initially, I too was a bit taken aback by the snake_case, but seeing as mori is quite different from other JS libs, the naming convention seems to suit it. Seeing update_in rather than updateIn does give me pause, but in that pause it makes me think harder about what is actually going on.

[nathansobo]

It's unfortunate, but aesthetics matter, and this convention just doesn't blend in with the typical JS naming conventions. Despite how awesome this library seems to be, I'm somewhat reluctant to incorporate it into Atom because I don't want to introduce naming inconsistency to the API.

[andrewdeandrade]

@nathansobo FWIW, immutable.js was just released by someone at Facebook. It was inspired by mori, but with a more JS friendly API. https://github.com/facebook/immutable-js HN discussion: https://news.ycombinator.com/item?id=8107447

[tgriesser]

Or you could always module.exports = require('camelize')(require('mori'))

[swannodette]

@tgriesser nice

[nathansobo]

After thinking on my previous comment, I hope I didn't come of as complaining. Just wanted to provide feedback on this point. I'm a big admirer of your work @swannodette.

[andrewdeandrade]

@nathansobo plus, to be fair, this isn't even a decision @swannodette made. Basically decisions in lein-cljsbuild are the reason for the funky naming convention.

[swannodette]

@nathan7 no worries. It's an occasional complaint, but Mori is now an old mostly unidiomatic JavaScript library and I don't really see the value in changing things up at the moment. I think there's value in immutable code sticking out for now - I might change my mind in the future which is why I haven't closed this ticket.

[swannodette]

@malandrew that's not actually true. Early on (> 2 years) back when hardly anybody in the JavaScript community was interested in immutable data structures I decided to use underscores simply to make the API stick out.

[cemerick]

@malandrew Just to further clarify: lein-cljsbuild is really just a thin leiningen shell around the various options provided by the ClojureScript compiler. It doesn't affect or impact naming in any way.

[swannodette]

fixed in master