@crocket: you at least get a partial order based on ns dependencies

What do you mean?

The order of side effects (like setting a dynamic var) are only guaranteed as a result of one namespace depending on another. I suspect this is relevant to your main question.

In concrete terms if namespace a depends on namespace b, then b can execute side effects that a can rely upon.

Does the namespace that sets *main-cli-fn* last wins? I'm not sure about exactly when *main-cli-fn* is executed.

@mfikes: My theory is that if namespace a(the :main namespace) depends on namespace b and both namespaces set! *main-cli-fn*, a gets to set *main-cli-fn* lastly, so a wins.

When I invoke clojurescript functions in nodejs, javascript allows to pass fewer arguments than function signatures to functions. How can I enforce arity in javascript?

I know that people just manually check for null in javascript.

This is what I would call a time for defensive programming. The function should be able to handle multiple arity.

That sounds simple but a little inelegant.

I disagree. If the function would just kick an error if the wrong number of arguments were sent, then yeah. But you could return (partial) functions and such which provides you the means toward composability on the caller side.

What if I want to enforce one arity in javascript runtime?

Think about it from the other direction: what do you want to happen if the arity isn’t correct?

Error

It’s an API issue. If you’re in control of both the Node side and the CLJS side then it’s up to you figure out the choke point (basically a façade pattern) between the two sides that will check that the n-arity is obeyed.

In clojure and clojurescript, arity is enforced. It's javascript that ignores arity.

Right. So either you put a façade of functions on the JavaScript side that throw on bad arity or you handle it on the ClojureScript side by having it return what you want on a bad arity.

I somehow hope that clojurescript adds arity enforcement on javascript.

I don’t. Personally, when I’m designing an API, I want it to be as flexible as possible. A throw is the very last thing I ever want anything to do.

Then, javascript semantics leak into clojurescript. It adds to my headache. I'd rather reduce complexity.

I’ve never found complexity reduced by nailing doors shut. Build a 10’ tall wall and someone will build a 12’ tall ladder.

And there’s always going to be a bit of an awkward dance between ClojureScript and JavaScript just because JavaScript is kind of unhinged anyway.

It’s why I usually shore up the CLJS side.

Please note that my use case is valid as well.

Oh, of course. I don’t mean to in any way suggest otherwise.

I’m just expressing my opinions based on my experience. When I’m doing interop, getting an exception from a call is quick to see but every time you get that, it’s a limitation you have to work around.

Limitation on mutability is a bless of clojurescript. The right kinds of limitation reduce complexity.

I like your edits.

I don’t mean to suggest that every function should be an n-arity free-for-all.

What I was trying to say is that you need to figure out where it is along the chain where you want to put the limitation. Do you do it on the JavaScript side? Make a wrapper around the calls to the CLJS stuff? Or do you buttress the CLJS functions and let them handle multiple arity by sending back partial functions so you kind of have a bit of currying so to speak.

I’m partial (ha ha) to the latter. I like the flexibility. Let the caller deal with the results but make sure it’s documented.

I like flexibility to the extent that it lets me avoid implementing things that I don't need in the foreseeable future.

But the API you’re working on isn’t always for you.

Or maybe it is but you might need something more from it seven months from now.

Flexibility lets me implement things that I haven't thought of before, so I can implement just what I need for now.

Without flexibility, I'd have to rebuild from scratch when some requirements are added later.

Right. Is it possible we’re saying the same thing but in a different way? Or maybe from a different perspective?

If clojurscript had support for enforcing arity, it'd be better. A compiler option would break a lot of things, so it may be a function or a macro.

[chuckles] Maybe so. As an option.

And a lot of what they do with ClojureScript and the direction in which it is urged is tied to what what, say, Google Closure lets them do. When you’re compiling—or transpiling or whatever—, you’re always at the mercy of the compiler and in our case, as far as I understand it, there’s only so much they can do.

To make matters more interesting, the development cycle of JavaScript is becoming increasingly rapid and they’re getting more bold. The next three years are going to be amazing to see.

ES6 may break clojurescript compiler.

There will be some work to be done, definitely. But there are some preternaturally smart people at work on Clojure and ClojureScript. I have a lot of faith in the efforts.

Thanks for the discussion, by the way; I had fun.

ok

@crocket: theres already some google closure stuff for es6 syntax https://github.com/google/closure-compiler/blob/04dd916be73f961f489906231cfb1a1ad0fd583a/src/com/google/javascript/jscomp/SubstituteEs6Syntax.java

I created a new leiningen template for writing clojurescript npm modules. https://github.com/crocket/cljs-npm-template

With this template, it is not hard to create an npm module in clojurescript.

@dnolen: thank you for all you’ve done with Om this year. I’m excited to see your progress with Om/Next in 2016.

@panesofglass: your welcome, looking forward to it as well

Would anyone have an exmple of how to use a react native ListView with om.next?

@hugod there is a #C0E1SN0NM channel for React Native discussion. You might have more luck asking there.

@adamfrey: thanks for the pointer