Error formatting macro: pagetree: java.lang.NullPointerException

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

UPDATE 06052013

Updated the page with input from David Nolen, the description of the prototype is left intact at the end of the page.

I concur with giving specify an extend-like interface, which can be passed functions.

Problem statement

The actual prototype of js objects is not settable. Thus it's not possible to assign a protocol implementation a to live objects, e.g. input from jsonp.

The fields needed to let a javascript object participate in a protocol could simply be assigned, however the algorithm to get the name-mangled protocol fields is woven into extend-type, tighly coupled to target the .protocol property.

Name, Interface?

There are plans for two macros: specify and specify!. Both have a syntax similar to clojure.core/extend, but take a target object in place of the type and are macros.

specify! will mutate the target object by assigning protocol methods as keys. This is mostly useful to create new prototypes, but can occasionally be useful for external objects from libraries or eval.

specify will clone the target object before specify! ing the clone.

Code Block
(specify! x
 {:-bar existing-fn
  :-baz (fn ([x] ...) ([x y] ..)})

The function implementing the method (existing-fn) will be called method-fn in this.


Giving specify an interface like extend has following difficulties

  1. Since there is one slot per method, you need to pass a multi-arity fn when implementing a multi-arity method.

    In a naive implementation, that would cost another arity dispatch, which already has been done at the method call site.

    This can be mitigated by having specify reuse the existing infrastructure for arity optimization: properties on the fn object called .cljs$lang$arity$* 

    specify can peel off those properties and use them as methods, which leads to the next cost

    1. A redundant fn object when implementing inline (the one that would do the arity dispatch otherwise)

      this could be mitigated by having specify recognize fn forms and emitting the arity-methods directly 
  2. specify will have to dispatch on the type(s) of method-fn

    the type being whether it has .cljs$lang$arity$*

    see Issues > Method arities 


Method arities

Since the arity dispatch is already done at the method call site, we want to directly call the appropriate arity of the method-fn. Since method-fns are lexically bound, we cannot statically know in all cases, how to get the target arity thunk from method-fn.

As the fallback, specify will have to look at the method-fn in every call (of specify!), but this could be mitigated, when the type of a method-fn is known from analysis.

Compatibility with external objects / Name clashes

Since specify may come into contact with external data, there is a risk of name clashes, since under advanced compilation method names are shortened to few characters.

specify should check if a property exists on the target object before assigning and should throw if so. This will also guard against double specification with possibly different method-fns.

For external data, such conflicts can and should be resolved with externs files.

Object methods and IFn

As per the refactoring from CLJS-414, generating (unmangled) Object methods is possible with (the private version of) specify.

When implementing IFn, extend-type generates a multi-arity fn and uses that as a call method. This hack was carried over into CLJS-414.

specify will generate arity methods, call and apply directly, when implementing IFn.

David, can you comment on how .apply vs .cljs$lang$applyTo are used?



I'm willing to implement the optimization for cost 1: to pull arity methods from the method-fn, if available. That would leave the overhead of the type dispatch(es) when invoking specify + a couple of redundant fn objects per specify call site.

Both could be thought of as confined costs, but I would like to make sure that they won't be show-stoppers, if nobody gets around to figure out how the specify macro could interact with the analyzer in such a way that they are removed. 

Proposal Description of prototype implementation as part of refactoring: CLJS-414

The operation to extend an instance will be called specify in the next proposal and have an interface similar to deftype. See discussion at CLJS-398




UPDATE 06052013

The refactoring done as part of this implementation will be rebased to current master with names specify and specify* set to private, until the design for specify is fully fleshed out.

Outline of the implementation