ClojureScript ^:export defprotocol

Discussion:

Mike Fikes

2014-06-18 17:56:25 UTC

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.)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Nolen

2014-06-18 18:34:24 UTC

Permalink

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

Post by Mike Fikes
Is there a way to indicate that a (ClojureScript) protocol is intended to
be used from the host?
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
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.)
--
You received this message because you are subscribed to the Google Groups "Clojure" group.
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
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
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gary Trakhman

2014-06-18 18:48:14 UTC

Permalink

'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 )

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

Post by Mike Fikes
Is there a way to indicate that a (ClojureScript) protocol is intended to
be used from the host?
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
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.)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
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
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Clojure" group.
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
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
For more options, visit https://groups.google.com/d/optout.

Mike Fikes

2014-06-18 19:43:11 UTC

Permalink

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

Post by 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
http://dev.clojure.org/jira/browse/CLJS-362 )

Gary Trakhman

2014-06-18 19:58:04 UTC

Permalink

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 :-).

Post by 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
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
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

Mike Fikes

2014-06-18 20:31:02 UTC

Permalink

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

Post by 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 :-).

Mike Fikes

2014-06-18 19:03:18 UTC

Permalink

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.

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

Mike Fikes

2014-06-19 15:27:03 UTC

Permalink

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

Is there a way to indicate the protocol names should be preserved?

Post by Mike Fikes
(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.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to ***@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+***@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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.