ClojureScript ^:export defprotocol

[Mike Fikes]

Is there a way to indicate that a (ClojureScript) protocol is intended to be used from the host?

Details:

I can define a protocol and an implementation of it in ClojureScript using defprotocol and reify. 

I can also successfully call methods on reified instances returned to the host (Obj-C embedding JavaScriptCore on iOS). 

The method names are mangled: In addition to the expected and usual conversion of hyphens to underscores, the mangled names incorporate dollar signs ($) and arity encoding, an example of which is:

  my$full$ns$MyProtocol$a_method_defined_in_this_protocol$arity$1

This can be called, passing this mangled string in as the method name of JSValue -invokeMethod:withArguments:.

All cool (so long as this mangling is stable from one ClojureScript release to the next—but it smells like the mangling could be an implementation detail, subject to change). 

The killer is if I turn on Google Closure advanced optimizations; these mangled names get renamed.

Is there a way to indicate the protocol names should be preserved? (Analogous to the way ^:export can be used on function definitions.)

[David Nolen]

On iOS is advanced compilation really necessary? :simple + :static-fns true should suffice.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gary Trakhman]

'any problem.. fixed.. by another layer of indirection'

You could also just make exportable functions that call the protocols, keeping them more as impl-details, core.cljs does this, and you gain things like varargs (hmm, do protocol-varargs work on cljs? nope: http://dev.clojure.org/jira/browse/CLJS-362 )

[Mike Fikes]

Even without JIT available in JavaScriptCore, I have been unable to notice a difference in the on-device performance of the “view controller” code I have been writing when turning on :advanced.

Thanks for the suggestion, I'll go with :simple and :static-fns. The reified protocol instance works with those optimizations.

[Mike Fikes]

Right, Gary,

Initially I simply wrote exported functions.

The motivation for experimenting with protocols is so that I can write a ClojureScript protocol that mimics, say the iOS UITableViewDataSource Objective-C @protocol. Then, with that in place, I can write ClojureScript reifications of that protocol to be passed back to Objective-C. It is then a simple matter on the Objective-C side to make that reification be a UITableView's dataSource delegate (with the help of a little reusable wrapper Obj-C object around the JSValue.) 

In addition to perhaps keeping things tidy (keeping like methods together), it makes it easier to pass multiple @protocol instances back to iOS. (Imagine the case of two or more table views on one iOS screen, each with their own distinct ClojureScriipt implementation.) 

Also, a lot of this ends up being boilerplate that needs to only be written once, and then, I recoup the costs of fleshing out this plumbing by simply spitting out a (reify ... ) form whenever needed.

Arguably, none of this is required because all of the UITableViewDataSource methods have the tableView as the first argument, which could be used by straightforward exported functions to dispatch or otherwise switch to the right implementation, which could in turn be a reified protocol. It just seems that, since Objective-C wants an object as a dataSource, that it would be interesting to try to satisfy that need (more or less directly) using the facilities available in ClojureScript.

I'll ditch all of this when Apple introduces FunctionalSwift along with functional APIs, and the Clojure(Swift) compiler targets that new language. :)

- Mike

[Gary Trakhman]

I was just telling a local ios dev there's like five guys using clojure + objective-c. To me it's impressive. To them, well, I don't know what they'd think :-).

On Wednesday, June 18, 2014, Mike Fikes <mike...@me.com> wrote:

--

[Mike Fikes]

That's cool. I see no reason why Clojure / ClojureScript's “reach” can't extend significantly into iOS.

[Mike Fikes]

I found the solution to the original question I had posed:

Is there a way to indicate the protocol names should be preserved? (Analogous to the way ^:export can be used on function definitions.)

You simply need to place the meta directly in the method signature forms, as illustrated here:

(defprotocol TableViewDataSource

  (^:export number-of-sections [this])

  (^:export number-of-rows-in-section [this section])

  (^:export cell-for-row-at-index-path [this section row]))

I came to this solution after reading the implementation of emit-protocol :)

With this change, the protocol methods can be called as regular functions from the JavaScriptCore / Obj-C host, even with :advanced optimizations enabled.