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
As a counterpoint to this, note that ClojureScript does the same thing (for
different reasons, but the same mechanism):
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/core.cljc#L91-L101
On 1 January 2017 at 05:24, Timothy Baldridge wrote:
> Be really careful with Po
Be really careful with Potemkin. I've had a lot of build issues (especially
around AOT) with that library. I'll try to put this as kindly as I
can...it's a bit of a hack that leverages some undocumented aspects of the
Clojure API. As such it's been the source of some really weird compile
errors tha
On Friday, December 30, 2016 at 8:59:46 PM UTC-5, puzzler wrote:
>
> 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 cons
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
Thanks Nathan! (See what I mean about my ignorance?)
On Friday, December 30, 2016 at 3:53:27 PM UTC-6, Nathan Davis wrote:
>
>
> 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 cycl
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
> restriction is ... ph
14 matches
Mail list logo
