2010/1/27 Seth :
> Michael,
>
> Thank you for pointing this out to me. After some thinking, I decided
> to lump all the defprotocols in one file; having all the APIs in one
> place seemed handy. But using (load) made it possible to keep deftype
> in its own file... though I did have to resort to (u
Michael,
Thank you for pointing this out to me. After some thinking, I decided
to lump all the defprotocols in one file; having all the APIs in one
place seemed handy. But using (load) made it possible to keep deftype
in its own file... though I did have to resort to (use) since (in-ns)
doesn't su
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, la
2010/1/24 Gabi :
> As a side note, I didn't see anywhere in clojure docs that cyclic
> references are forbidden.
Yeah, and that's why I didn't employ (or intend to ?) the word
"forbidden", but rather the words "smells" and "software principles".
Smells and principles and general guidelines. Somet
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 wrote:
> Some software principle are certai
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 conc
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 horribl
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.
Think about it from the point of view of someone wanting to call your
You know what? I am not sure that it smells so bad actually. What if I
have 2 modules that collaborate with each other and use each other
functions ? Why is this so bad?
On Jan 24, 5:32 pm, Laurent PETIT wrote:
> Short answer: you can't. And yes, it's a "smell" (a bad one) if you
> want to achi
Short answer: you can't. And yes, it's a "smell" (a bad one) if you
want to achieve this.
You have to somehow break the cycle :
* maybe acknowledge that ns a & b are strongly coupled since there's
the need for a cyclic dependency, and merge them.
* sometimes one wants to have a & b to have th
10 matches
Mail list logo
