On Feb 10, 7:15 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> Hello,
>
> 2009/2/10 Stephen C. Gilardi <squee...@mac.com>
>
>
>
>
>
> > On Feb 10, 2009, at 11:46 AM, Laurent PETIT wrote:
>
> > If I understand correctly your proposal, can you verify the following is
> >> true :
>
> >> (ns foo.bar)
> >> (ns foo.bar.util)
> >> (ns foo.bar.impl)
> >> (ns foo.bar.data)
>
> >> with foo.bar decomposed in two files : foo/bar.clj and foo/bar1.clj just
> >> one file per ns, would result in the following structure :
>
> > Do you mean foo/bar/bar1.clj? I don't understand "just one file per ns"
> > given that there are two files associated with (ns foo.bar).
>
> Yes, that's what I meant, as the following example suggested.
>
>
>
>
>
> > /foo/bar.clj
> >> /foo/bar/bar1.clj
> >> /foo/bar/util.clj
> >> /foo/bar/impl.clj
> >> /foo/bar/data.clj
>
> >> So now, /foo/bar/ holds all the declarations of namespaces of 3 segments
> >> whose prefix is foo.bar , plus all the extra files needed for namespace
> >> foo.bar ?
>
> > Assuming you meant that foo.bar is in two files foo/bar.clj and
> > foo/bar/bar1.clj above, the layout you gave is correct under my proposal.
> > The ns declaration beginning "(ns foo.bar" would include a clause "(:load
> > "bar1")".
>
> ok
>
> > Since it does not allow to infer by convention which file represents a lib,
> > and which file not, I think I prefer the current way of having the
> > possibility to keep all ns related files in the same directory, if I want
> > to.
>
> > If you work with several libs that share common prefixes and have different
> > numbers of segments, you are not able to infer which are libs and which
> > which are load files--either currently or with my proposed change.
>
> You said it : "either currently or with my proposed change". That's what I
> wanted to point out : since the proposed change does not solve anything new,
> the problem is just a "balance" between having the freedom to easily place
> files at the same level of your main lib-defining file, or one level deeper.
> As far as I'm concerned, I see no real gain in the new proposal, so sticking
> with the current way of doing things (with the possibility to have any
> layout I want) is sufficient to me.
>
I agree, and therefor am not in favor of this change.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
