On 9/27/05, Ryan Davis <ryand-ruby / zenspider.com> wrote:

> That is a circular dependency. Plain and simple. It doesn't matter if
> you prefer to call it a "mutual" dependency because "they don't
> actually depend on each other to do anything"... except that
> "require" line of course. That require line is a "do" and "require"
> === "depend".
>
> I think the key word in your paragraph above is "want" and reeks of
> bad design smell.

No it's not. What I "want" is prefectly legitimate. I have many small
libs a user can call upon, some of those are closely related so they
should "tag along". Call it what ever the heck you want, I used the
term "mutual" simply to differentiate from "circular". Call it a
"you're-my-friend" dependency, if it suits you better. I don't care.
The point is if the end-user requires t1.rb then t2.rb should also be
available. If they require t2.rb then so should t1.rb --without
double-loading --no circular dependecy involved.

Ironically enough, I have the same problem with Gems. Why? B/c I have
two projects: Nano and Mega. Each depends on the other for certain
resources --none of it circular. But alas I can't specify the mutual
dependency b/c Gems chokes on it. Same basic misconception.

Moreover if you consider your own reasoning more carefully, you'd see
it actually supports my "want": the problem is a double-loading
--which is a very real circle, and the one you are actually talking
about. So as can be atested by the very real double-loading, Ruby is
not presently doing dingy about circular dependencies. I'm actaully
discouraging them!

All I'm asking is that, if possible, Ruby not require a file it's is
currently in the middle loading. Maybe ther are very ral reasons it
cannot do this. If so I would like to hear them. But don't tell me my
program smells --that completely forgoes the issue.

T.