>
> (load "foo") is legal Clojure; if a tool can't handle it, that's either a
> bug or a deliberate limitation in the tool.
This is not true. Cursive, for example, indexes Clojure projects in order
to perform its magic. In IntelliJ, index data for a file is only allowed to
depend on the contents of that file, not any other. This is a very common
restriction in indexing systems, since otherwise you need to maintain
dependency information with your index items and invalidate them when one
of potentially many files is touched. Splitting a namespace across multiple
files using load-file is impossible to handle correctly with this
restriction. Cursive contains a metric truckload of heuristics to try to do
intelligent things in this case (and generally does ok at it) since
clojure.core does this, but I would definitely discourage anyone interested
in tool support from doing this.
On 4 June 2014 04:15, Gregg Reynolds <d...@mobileink.com> wrote:
> On Tue, Jun 3, 2014 at 9:51 AM, Phillip Lord <phillip.l...@newcastle.ac.uk
> > wrote:
>
>> Gregg Reynolds <d...@mobileink.com> writes:
>>
>> > 4. Put your helper funcs ("defn-" stuff) in helpers.clj, without a
>> call to
>> > ns at the top, then (load "helpers") at the top of the file that uses
>> them.
>> > You still get the effect you're looking for, with a one line "preface"
>> > that tells the reader where to look for more info. Seems to work in a
>> > little test app (lein new app topdown):
>>
>> This is not side-effect free (sorry for pun). I did this for my code,
>> and now slamhound doesn't work on it. Other tools too? I don't know.
>>
>> https://github.com/technomancy/slamhound/issues/61
>
>
> (load "foo") is legal Clojure; if a tool can't handle it, that's either a
> bug or a deliberate limitation in the tool. In the case of slamhound, I
> guess it's a deliberate limitation. On the other hand, when I followed the
> instructions on the slamhound page and ran it against my directory it
> overwrote helpers.clj from
>
> (defn- hello [] (println "Hello "))
>
> to:
>
> (ns hello)
>
> which looks like very rude behavior to me - I won't be using slamhound
> anytime soon. So I wouldn't say that using "load" has side-effects that
> break tools, but that some tools may make assumptions and have side-effects
> that do nasty things to legal code (or "encourage" a particular style). I
> would not be surprised if other tools make similar assumptions about the
> structure of clojure source files. Then it's a question of whether one
> wants to allow the limitations of tools to constrain one's use of the
> language.
>
> -Gregg
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
