http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJS-414 ClojureScript <p>Javascript objects are fully dynamic. Currently, ClojureScript has no mechanism to exploit that for protocol implementation. </p> <p><a href="http://dev.clojure.org/jira/browse/CLJS-398" title="new macro cljs.core/extend-instance"><del>CLJS-398</del></a> was a first attempt to implement an operation to extend single instances, but it fell short because it offered no control over which closures to attach onto the object (i.e. allocates every time). Also, specify is a much better name than extend-instance.</p> <p>extend-type can be implemented in terms of specify (by specifying the .prototype), but extend-type has grown from its humble beginnings <br/> <a href="https://github.com/clojure/clojurescript/blob/b75730da8abc3abc6134d8dd9ec426ab792d3662/src/clj/cljs/core.clj#L42">https://github.com/clojure/clojurescript/blob/b75730da8abc3abc6134d8dd9ec426ab792d3662/src/clj/cljs/core.clj#L42</a><br/> to an monster of complexity<br/> <a href="https://github.com/clojure/clojurescript/blob/72e55315c6973caa74af39b66052424f73872033/src/clj/cljs/core.clj#L438">https://github.com/clojure/clojurescript/blob/72e55315c6973caa74af39b66052424f73872033/src/clj/cljs/core.clj#L438</a><br/> Currently it does</p> <ul class="alternate" type="square"> <li>print warnings</li> <li>optimize IFn impls</li> <li>special case the Object "protocol"</li> <li>special case js builtins</li> </ul> <p>and all that in a single macro body. So this is also a good opportunity to do some refactoring.</p> <p>specify should have an interface similar to extend-type. Additionally a lower level operation is needed to attach existing lambdas as protocol methods. It's called specify* in my current implementation. It takes a lambda for every specified protocol-method-arity, with a syntax loosely based on clojure.core/extend.</p> CLJS-414

Implement specify, allowing instances to implement protocols

Enhancement Major Open Unresolved Herwig Hochleitner Herwig Hochleitner Tue, 30 Oct 2012 23:08:22 -0500 Fri, 3 May 2013 19:30:54 -0500 0 1 <p>First patch implements specify, second switches extend-type to use it.</p> <p>This is a big patch so it's going to take time to review. First question, if we're going to follow the footsteps of extend what's the purpose of changing the syntax like having to specify a map of arities?</p> <p>The reason is that I wanted specify* to do as little as possible. It's basically just an abstraction over the name mangling for protocol methods, which was completely hidden till now. One of the purported use cases is:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">(def methA-1 [<span class="code-keyword">this</span>] ...) (def methA-2 [<span class="code-keyword">this</span> x] ...) (def methB-1 [<span class="code-keyword">this</span>] ...) (defn specify-to-P [o] (specify* o P {methA {1 methA-1 2 methA-2} methB {1 methB-1}}))</pre> </div></div> <p>Here the method bodies are not allocated every time specify-to-P is called, as opposed to what the more high-level specify would do. If we didn't know which arities are to be generated, there would be simply no way to infer it:</p> <ul class="alternate" type="square"> <li>there is no simple way to know at compile time which arities an fn has</li> <li>if there was we wouldn't be able to get the fn at compile time in all cases</li> <li>defprotocol doesn't expose it's methods or their arities</li> </ul> <p>EDIT:</p> <p>As for using symbols instead of keywords: I could do this, since specify* is a macro, not a function.<br/> Making specify* a function may have its own merits, which I frankly hadn't thought about. Actually, that might be sweet, I'll look into that possibility.</p> <p><del>As for specify* being a function: It uses a map in its syntax and at the same time is used to define PersistentHashMap, so that wouldn't work.</del><br/> EDIT: the real reason is name mangling, see comment below</p> <p><del>What could conceivably be done is to have a core function</del> (specify-method <span class="error">&#91;proto method arity impl&#93;</span>).<br/> EDIT: can't be done without reflection, same reason</p> <p>That way we could support consumers that want to determine the set of implemented protocols at runtime, similar to extend. This can be a separate ticket where we work out whether it's :method 'method or "method".</p> <p>As for specify* using symbols: My gut feeling tells me that since it will always be a compiler macro (or builtin) and takes the arities, there is no merit in making it superficially more similar to extend.</p> <p>OTOH, it occurs to me that given specify-method, we could leave out specify* completely. I think I'll try that when I get home from work. Thoughts on that approach?</p> <p>Actually, I had a rationale for using symbols in specify*, which I just now rediscovered while trying to implement aforementioned specify-method.<br/> It uses symbols to highlight the fact, that the method names are subject to the same (gclosure) minification as every other name.</p> <p>This is also the real reason specify* (or specify-method) can't be a function: It would need a reflective layer to go from <span class="error">&#91;proto method arity&#93;</span> to the <em>gclosure minified</em> version of $proto$method$arity$a. We don't have that in clojurescript, since it would considerably add to the output size.</p> <p>Considering that all, I think specify* in the current form is appropriate after all.</p> <p>Nevertheless I found an unrelated issue in the patch where 'Object would be resolved (with an unused result), triggering a warning. I added the 0001_1 patch, which supersedes 0001 and is functionally equivalent modulo the warning issue. 0002 still applies.</p> <p>Attached patch set 01** supersedes patch set 00**</p> <p>The differences are</p> <ul class="alternate" type="square"> <li>Make ^:skip-protocol-flag work</li> <li>Added tests</li> </ul> <p>Set up a design page <a href="http://dev.clojure.org/display/design/specify+i.e.+reify+for+instances">http://dev.clojure.org/display/design/specify+i.e.+reify+for+instances</a></p> <p>Attached patch 0104, applies on top of other 01* patches.<br/> It adds capability to specify* IFn and allows specify* to take an expression too.</p> <p>rebased to current master<br/> see also <a href="https://groups.google.com/d/topic/clojure-dev/1UegnkLSwhE/discussion">https://groups.google.com/d/topic/clojure-dev/1UegnkLSwhE/discussion</a></p> Global Rank