lynaghk / cljx

Write a portable codebase targeting Clojure/ClojureScript

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is automatic symbol replacement worth it?

cemerick opened this issue · comments

The sjacket branch now has symbol replacement (e.g. clojure.lang.IFn => cljs.core.IFn).

After looking into expanding this significantly (with the objective of providing at least a full mapping of Clojure interfaces => ClojureScript protocols), I'm think that it's not such a good idea. While there's a sizable correspondence between the names involved, it's far from uniform: ClojureScript has many, many more protocols than Clojure has interfaces, and the methods defined by them are arranged in a couple of cases slightly differently. We could provide automatic replacement for the ones that are directly analogous, but then users would be left having to know/remember which protocol name changes are taken care of and which aren't.

Beyond that, it seems like the real pain around protocols isn't their names, but their methods. The camelCase vs. -dash-prefix conventions are consistent in many places, but post-ClojureScript Clojure protocols have been following that movement and also using -dash-prefix method names; do we always presume that people are writing Clojure and convert when emitting ClojureScript? What happens with "userland" protocols that use the camelCase convention?

I'm strongly leaning towards abandoning this particular feature (though cljx master only replaces two symbols as it is, IFn and Atom ;-P). Thoughts?

This is the last item to consider before I'd recommend merging sjacket to master; my preference would be to drop symbol replacement from the default cljs ruleset, and revisit the issue for a later release.

Hey @lynaghk, any leanings here? I think you were the biggest proponent of the symbol replacement feature in general…?

Dropping it sounds fine to me; you're right that it's better to have comprehensive, thought out support rather than just one or two cases.

OK, that default cljs rule is now gone on the sjacket branch, new SNAPSHOT pushed.

Closing this for now; we can revisit at a later date with a more comprehensive approach.