I think Timothy Baldridge had a great answer. For example, I often have
records which use each other's constructors. But you can put your factoy
methods in a map of dependencies.
I generally have a build function which takes a hash map as an argument,
associates the various data and functions t
while allowing cyclical references when needed.
>>>
>>
>> The macros defined in ‘scarlett.core’ here: https://github.com/scgil
>> ardi/scarlett are an experiment along those lines.
>>
>> *scarlett*
>>
>> Provides macros to declare vars in
/github.com/
> scgilardi/scarlett are an experiment along those lines.
>
> *scarlett*
>
> Provides macros to declare vars in namespaces other than *ns*
>
> To be used sparingly to overcome otherwise cyclic namespace dependencies
>
> *Usage*
>
> (ns-declare my-
efined in ‘scarlett.core’ here:
https://github.com/scgilardi/scarlett are an experiment along those lines.
*scarlett*
Provides macros to declare vars in namespaces other than *ns*
To be used sparingly to overcome otherwise cyclic namespace dependencies
*Usage*
(ns-declare my-module startup shu
On Friday, December 30, 2016 at 7:59:46 PM UTC-6, puzzler wrote:
>
> On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge > wrote:
>
> I wonder whether there could be something like an `external-declare` that
> would satisfy Rich's concerns about knowing how to intern unencountered
> vars, while
Aaron, thanks for the RH quote. I had looked at parts of that Yegge
discussion at one point, I think, but I don't recall reading this section
of Rich's remarks. I never succeeded in understanding Common Lisp packages
well enough to use the successfully. I tried and gave up. Rich may be
poin
On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge
wrote:
> I can see that, and even spec has this use case. In Spec it's solved by
> having both A and B in one namespace and using declare to forward-declare
> the constructors (or defns in this case).
>
> So I guess the way I see it the tradeoff
I can see that, and even spec has this use case. In Spec it's solved by
having both A and B in one namespace and using declare to forward-declare
the constructors (or defns in this case).
So I guess the way I see it the tradeoff is a declare and
all-in-one-namespace vs a massive complexity additio
On Fri, Dec 30, 2016 at 4:38 PM, Timothy Baldridge
wrote:
>
> So the layout looks like this:
>
> Interfaces.clj
> |
>
> | |
> ImplementationA Implementation B
> | |
>
I feel your pain. I also run up against this time and time again and view
it as a significant limitation -- one which often forces me to contort the
structure of my Clojure programs into something less natural. And as the
Clojure language grows, the problem becomes even more acute.
For example,
I've been programming Clojure for something like 6 years now, and yes, I've
hit the cyclic dependency error a few times. How did I solve it? Each time
via abstraction, and parameterization of functions. Most of the time this
means writing a "interfaces.clj" file that contains all my defprotocols an
You already know this has been discussed a lot over the years.
I just wanted to cite the best reasoning that I've seen from Rich about why
Clojure does it the way that it does, which I believe is the argument that
surrounded an blog post fro Steve Yegge that Rich responded to and some
excellent di
t;> compiler won't allow cyclic namespace dependencies. I am not a
>> compiler-writer, but as far as I can tell the only reason for this
>> restriction is ... philosophical. It forces bad code organization, and it
>> wastes time. Those who think that cyclic code is an
On Friday, December 30, 2016 at 10:13:49 AM UTC-6, Mars0i wrote:
>
> I love Clojure. But: My number one complaint about it is that the
> compiler won't allow cyclic namespace dependencies. I am not a
> compiler-writer, but as far as I can tell the only reason for this
I love Clojure. But: My number one complaint about it is that the
compiler won't allow cyclic namespace dependencies. I am not a
compiler-writer, but as far as I can tell the only reason for this
restriction is ... philosophical. It forces bad code organization, and it
wastes time.
15 matches
Mail list logo
