Cljs support (WIP)

[venantius]

This is just a start; there's a bunch of stuff that'll need to be changed and I wanted to go through some of it in a somewhat interactive form rather than going too far down the rabbit hole and finding out that wasn't a direction we agreed on.

[venantius]

I have some thoughts:

1. JavaScript does not have an inheritance model in the same way that Java does. We can check that a given object satisfies an interface, for instance, but there isn't really chained inheritance the way there is in Java.
2. Checking for basic types is obviously going to be different. We would dispatch on js/Number rather than java.lang.Integer etc.
3. I find the puget.dispatch namespace confusing.

I don't really understand how the library works right now, so just at a high level I'd like some clarification that I really understand what's going on. My understanding of the code is as follows:

• We have various maps, for instance, puget.printer/java-handlers, where the keys are references to classes and the values are the print-functions
• When we try to call dispatch on a value, it looks up the corresponding value for its key in the map based on the results of a call to class on the value, and calls that on itself to try to print the value. If it can't find anything it falls back to a default print method of java.lang.Object

It would seem to me that since class doesn't exist in ClojureScript, we'd end up adopting a very different approach - one based first on checking type, and then after that using satisfies? to check against known interfaces (possibly). Unlike in Java, we don't have the option of calling, .getInterfaces on the class itself.

Thoughts @greglook ?

[greglook]

JavaScript does not have an inheritance model in the same way that Java does.

This is going to be a little different, but I think the cljs code should check direct implementations/protocols rather than worrying about inheritance. That should solve most of the use-cases.

I find the puget.dispatch namespace confusing.

A lot of the code is for logical dispatch, to factor out common patterns for doing inheritance-style lookups in Java land. In a way, it's a simplified version of Clojure's multimethod/hierarchy dispatch.

[greglook]

For exceptions, I think a better route is to use the platform-agnostic ex-info constructor.

[venantius]

TIL

[greglook]

It seems like a lot of the changes are format-related - please don't change the existing code style. It also makes the diff harder to read.

[venantius]

Yeah, sorry, I just ran cljfmt on the project and it changed a bunch of things. Would you be open to a separate alignment PR for the cljfmt stuff?

[venantius]

Upstream PR for arrangement will need to happen for this as well: greglook/clj-arrangement#1