Honestly, writing clear understandable code is hard enough already.
I have voiced this opinion before in other discussions on this topic - but my
view is that inline feature expressions should be used very sparingly. And
preferably, there should also be other options for portability - e.g. separ
> I personally think the CL feature expression approach is satisfactory.
The more I think about it, the less I think that the CL Feature Expression
approach is satisfactory as is.
I'm now reasonably convinced that, horror of horrors, we should look to the C
preprocessor for inspiration.
CL's a
Oh, yes please. This looks very interesting.
Where can I vote? :P
The more CLJ/CLJS code I write the more I miss a straightforward way to
share code. Even with cljx or cljsbuild crossovers its still a workarround.
On Saturday, February 16, 2013 7:20:45 PM UTC+1, David Nolen wrote:
>
> I've on
I've only glanced at it but Roman's patch looks pretty straightforward, it
should be pretty simple to port to tools.reader if the tools.reader folks
are OK with this approach.
I think the reason it has stalled is that there been some pushback on that
design thread. I don't really share any of the
Hi David,
do you think that with some guidance from few cli/cljs gurus the effort could
be shared with less experienced clojurist ? Or it's more efficient to let those
gurus to make a step ahead by themselves?
mimmo
On Feb 16, 2013, at 5:53 PM, David Nolen wrote:
> I personally think the CL f
I personally think the CL feature expression approach is satisfactory. I'd
like to see this get into 1.6. It's likely that ClojureScript will switch
to tools.reader in order to get more accurate information for source maps,
so perhaps we can move more quickly if we just implement it there.
On Sat
