Hi everyone. I think for the moment I will agree that it would bring more
pain to allow circular imports in Go than it would solve problems. One of
the most convincing arguments I have read here so far is that it would
probably cause many design flaws all around and make many packages very
hard to
Anecdote: A (large) Java project I worked on ran into trouble with cyclic
dependencies so often, that they started introducing conventions like
"classes under directory X are not allowed to import classes under
directory Y (but vice-versa)", effectively emulating Go's prohibition of
cyclic imports
I find the same, but eventually I come up with a way to clarify. Just *Not
Real Soon* (;-))
>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I've found that I end up lumping a bunch of things together into a much
larger package than I'd prefer precisely because there is often no good way
to break a logical piece out into its own package without creating a
circular dependency. For me at least, this makes the code harder to
navigate
In my view, Go's prohibition on cyclic imports is perhaps *the* single most
important feature that keeps large Go projects sane.
There are numerous occasions in the last few years when we would have used
cyclic imports if they were available, and in every case it would have been
a mistake. In
On Fri, Nov 30, 2018 at 6:50 AM Michel Levieux wrote:
>
> Hi guys,
>
> I've been trying to find examples of cases where it is complicated to
> structure the project because circular imports are forbidden, but I can't
> find something simple that I can show you. The thing is when I've been
>
On Fri, Nov 30, 2018 at 8:50 AM Michel Levieux
wrote:
> Hi guys,
>
> I've been trying to find examples of cases where it is complicated to
> structure the project because circular imports are forbidden, but I can't
> find something simple that I can show you. The thing is when I've been
>
I've been trying to find examples of cases where it is complicated to
> structure the project because circular imports are forbidden, but I can't
> find something simple that I can show you. The thing is when I've been
> confronted to such cases, it was with large projects, and I have no
Hi guys,
I've been trying to find examples of cases where it is complicated to
structure the project because circular imports are forbidden, but I can't
find something simple that I can show you. The thing is when I've been
confronted to such cases, it was with large projects, and I have no
And to reduce build time, especially for incremental builds.
-rob
On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor wrote:
> On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux
> wrote:
> >
> > The last few days I've been thinking a lot about the fact that Go does
> not allow circular imports.
> >
On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux wrote:
>
> The last few days I've been thinking a lot about the fact that Go does not
> allow circular imports.
> I'm not really sure of why it currently works that way, but from what I've
> understood the way the compiler works - which is also the
On Thu, Nov 29, 2018 at 2:22 PM Michel Levieux
wrote:
> The main reason why I'm strongly convinced forbidding circular imports is
not a good thing is that it separates too much the problem space from the
solution space.
TBH, I cannot even figure out how could _possibly_ circular imports work.
Can I suggest you provide a real example to help motivate why you
think circular package imports should work, and therefore what they
would solve?
I will note that circular module dependencies are possible and have
good reasons to exist
The last few days I've been thinking a lot about the fact that Go does not
allow circular imports.
I'm not really sure of why it currently works that way, but from what I've
understood the way the compiler works - which is also the reason why
compilation of Go programs is much faster than other
14 matches
Mail list logo
