No support for cyclical dependencies is biting me too. I'm trying to use one .clj file per protocol&type, which doesn't seem *too* smelly. It's a habit that goes way back... maybe time to revise my worldview :-)
If a namespace is intended to be a stratum then I will refactor to fit that. Fewer, larger files are just a little more awkward to deal with. On Jan 24, 4:27 pm, Gabi <bugspy...@gmail.com> wrote: > As a side note, I didn't see anywhere in clojure docs that cyclic > references are forbidden. > And if it is forbidden, the Exception raised by the runtime should > reflect this instead of the odd "No > such var->.." exception > > On Jan 24, 10:44 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote: > > > > > Some software principle are certainly above the languages used to > > solve a problem, even probably above programming paradigms (OOP, > > purely functional, etc.). > > > Java certainly has good parts, and having promoted the role and > > importance of interfaces must certainly be accounted to its credit. > > > But concerning the problem at hand, I think one could make an easy > > parallelism between callback classes in java and higher order > > functions in functional programming. It's just that's it's sooo easier > > and feels so much natural to do it in clojure ! :-) > > > I agree with Stuart Halloway's answer, nothing more to add. > > > I would just like to add that the term "module" has been used at one > > point where at first the debate was on namespaces. > > I'm not quite sure the notion of module I have in mind is really > > possible via the use of namespaces. For example (at least in the way > > I've learned and currently understand the concept of a module) it > > should be possible to load at the same time several "instances" of a > > module in an application, possibly even different versions of the same > > module. (of course to be used by different parts of the application). > > Not so much with namespaces. And I think that it's not their goal as > > well. > > > But I can understand what the OP wanted to do. Those sort of things > > can be done with java packages, and the java compiler can also very > > easily allow one to make classes depend on each other in a circular > > manner. > > And since clojure and lisp in general is all about allowing the user > > to shoot himself in the foot by bringing the maximum power to him, I > > can understand the complaint. Same can be said concerning > > interdependent functions. > > > Cheers, > > > -- > > Laurent > > > 2010/1/24 Heinz N. Gies <he...@licenser.net>: > > > > On Jan 24, 2010, at 17:12 , Stuart Halloway wrote: > > > >> If the collaboration is deeply entwined, the two modules should be one > > >> module. If one module uses another, but with occasional callbacks in the > > >> other direction, use an interface or a protocol to define the > > >> backchannel. > > > > That sounds horribly Javaish :(, I solved a problem like this by moving > > > out the parts that A and B needed to C, but it kind of is sad that since > > > it feeled so much like Java here especially when it comes to interfaces > > > and things like that ... > > > > -- > > > 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 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
