Versions Compared


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


Update 290513: I've implemented generating .cljs$core$IFn$_invoke$arity$ methods and .cljs$lang$applyTo along with .-cljs$lang$maxFixedArity and a wrapper for .call. Surprisingly, this seems to slow down IFn invokations slightly, at least on my machine, despite the generated code looking pretty optimal: and - Herwig

The slowdown issue has been resolved by type hinting. An area I want to explore is the possibility of using a single .call method for all fns (containing a switch and pulling the arity off this). - Herwig

Method names

Should the method names be written as symbols instead of keywords? extend has keywords, but it's a function.


there's also the added benefit of specifying maps of fns at the macro level and merging them there. This one is probably worth asking the community about once the proposal is more fully baked - David

Protocol method calling convention

Right now there is a special case, where IFn$_invoke is called without the otherwise usual first this parameter. I will explore the possibility to remove the redundant first parameters from other protocol methods aswell. Specify will need to introduce the binding via this-as or a wrapper function in the case of external implementations. - Herwig



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.