Detect changes in namespaces split over several files #10

Merged
merged 1 commit into from Feb 2, 2013

2 participants

@hutch

Addresses open issues #1, #7, #8, and #9

  • will now re-load namespaces if a source file that is explicitly loaded changes. This will only work if the first non-comment form of the 'helper' or 'extension' source file is an (in-ns) form. It will not look for any subsequent in-ns forms in the file. This is the same idiomatic usage of load/in-ns that is found in clojure/core.
    • newer-namespace-decls returns a list of ns-decls (as before) but also a set of namespace names (symbols) that have been affected.
  • avoid calling .fileModifed twice for each source file
  • replace contains? (as in ahjones/ns-tracker@1648229)
  • use tools.namespace 0.2.2 (similarly to jakemcc@6884b4c)
  • use clojure 1.3.0 (required by tools.namespace)
@hutch hutch -- will now re-load namespaces if a source file that is loaded changes.
   This will only work if the first non-comment form of the 'helper' or
   'extension' source file is an (in-ns) form. It will not look for any
   subsequent in-ns forms in the file. This is the same idiomatic usage of
   load/in-ns that is found in clojure/core.
-- newer-namespace-decls returns a list of ns-decls (as before) but also
   a set of namespace names (symbols) that have been affected.
-- avoid calling .fileModifed twice
-- replace contains? (as in
   ahjones/ns-tracker@1648229)
-- use tools.namespace 0.2.2 (similarly to
   jakemcc@6884b4c)
-- use clojure 1.3.0 (required by tools.namespace)
5b3d9ff
@hutch

I just noticed that I didn't remove a println -- line 130 of core.clj.

@weavejester
Owner

I'd be avoiding the upgrade to Clojure 1.3.0 because I wanted to retain support for older versions of Clojure in Ring for as long as possible. However, I suspect that I'll need to bite the bullet and upgrade.

@hutch

I wasn't aware you were trying to avoid the upgrade. There's very little of clojure.tools.namespace actually used, three methods, two of which are trivial. I would think it's possible to avoid the upgrade with some small changes to what I did.

@hutch

Though with 1.5 imminent you have to wonder how far back you're prepared to support.

@weavejester
Owner

Given that 1.5 is probably going to be out at the same time as Ring 1.2, maybe it's reasonable to have a policy of supporting Clojure 2 versions back.

@hutch

That sounds perfectly reasonable to me.

@weavejester weavejester merged commit 882ed8d into weavejester:master Feb 2, 2013

1 check passed

Details default The Travis build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment