Stop using metadata notation about cljx HOT 6 CLOSED

Is there an advantage of the feature-expression syntax you proposed vs. metadata beyond the semantic cleanliness?
(Which itself is not obvious to me---isn't a form's expected runtime metadata about that form?)
Couldn't we do per-build features with metadata as well?

from cljx.

My basic thought is that different things should look different. When you're using cljx, ^:clj and ^:cljs are not metadata, even though they look like it. Maybe an argument can be made that they are metadata, just not of the runtime variety, but I think it's worth not getting into such subtleties.

Yeah, we can do extensible per-build "features" with metadata, but we (and any user, perhaps unwittingly) will just end up impinging upon that "namespace" even more. i.e. even more metadata is subject to conditional elision, e.g. ^:jvm, ^:debug, ^:only-for-customer-A, etc.

from cljx.

I think that's a reasonable argument for switching to feature expressions.

How far do you want to take them?
Annotating forms with structured data and doing queries to determine what to include/exclude?

from cljx.

Definitely wasn't planning on going that far, at least not to start. I'm not sure many people actually want to "query" their code (various other higher-order projects aside); just the equivalent of a pile of defines (a set of enabled "features" per build), and I suppose an optional seq of transformation fns, (as it is now) so we can continue to provide sane defaults for cljs around comment, defmacro, etc.

In the end, the practical user experience won't change much at all, i.e. I'm guessing there's ~3 people that ever wrote new kibit rules for use with cljx. Two curated presets (one for each target) + a knob to add additional features / degrees of freedom should do it.

from cljx.

I say go for it, then.

from cljx.

Done. :-)

from cljx.