Why macros?

[nchurch]

I was taking a look at Enfocus again after a long hiatus (right now
I'm using Domina) and noticed that most of the documented code is
macros----for instance, even get-text, get-prop, etc. (which are just
wrappers around en-get-text, etc.). I admit I may understand more if
I use Enfocus more, but why the emphasis on macros? You can't use
them as higher-order functions (which is exactly how I would be
inclined to use something like get-text). What do you gain by using
macros, rather than lose?

Thanks,

Nick.

[Creighton Kirkendall]

Nick,

I am shocked more people haven't asked this question.  Those macro shadows are first on the list of items that will be removed in 2.0 iteration of Enfocus.   Overtime the reasons for the macros have faded as the ClojureScript compiler became more mature.  Originally, they created for performance issues around multi-arity dispatch and limitations to the ClojureScript namespace macro.   By the time these issues were addressed I had several people using enfocus on significant projects, so I decided to leave the shadows in place for the 1.0 release to avoid breaking these projects.   People got around the composability issues by dropping down and using the core functions when they needed this functionality.  The 1.0 release will be going out this month and I will begin working on the 2.0 branch.  

CK   

--

---
You received this message because you are subscribed to the Google Groups "Enfocus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enfocus+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[nchurch]

Thanks Creighton! That helps a good deal-----any recommendations for
what to do in the meantime, for forward-compatability? It looks like
the macros namespace is a mixture of pass-throughs, non-trivial macros
that could be functions, and natural macros such as def forms. Should
we just use core functions wherever feasible? Will these be renamed
in 2.0?

On Feb 23, 4:27 am, Creighton Kirkendall <ckirkend...@gmail.com>
wrote:

[Creighton Kirkendall]

Nick,

It will probably be broken up into a series of namespaces.   You can do two things to make sure the future changes will be easy to manage.  First you can :use with aliases for the items you want to compose.  Second you can use :use-macros to make sure when the namespace changes the code change will be limited to the namespace macro.

CK 

[ckirkendall]

Nick,

I pushed up 2.0.0-SNAPSHOT without macro shadowing. It passes all test. I am debating on moving effects and event management into separate namespace but haven't made a decision yet.

CK