24-Apr-2013 20:08, qznc пишет:
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky wrote:
Basically an import graph of Phobos is a rat's nest of mutual imports.
With the most of modules being template "toolkits" you shouldn't pay
for what you don't use. Yet it isn't true in general as the module may
drag in other modules and with that all of static constructors and/or
globals related.
Thoughts? Other ideas?
I think your concept idea introduces unnecessary complexity.
It reduces the complexity of full module imports and helps avoid
circular dependencies. Problem is that compiler can't know that all you
need that module for is a few isolated templates.
If compiler sees this:
module abc;
import xyz;
That means that
a) abc depends xyz and thus all of the global state in xyz if there are
any. Cue to the idea that globals are bad - you can't easily track the
usage of them esp. with separate compilation model.
b) if xyz happen to use stuff from abc compiler has to "turn on" cross
module dependency checks and define the order of ctor/dtor evaluation.
More importantly in current setting is the fact that it's not good at it
and conservative (as it may as well stay forever).
c) It may be the case that both modules define ctors and then you have
genuine circular dependency.
d) Another (bogus) case is that it may as throw up hands in the air and
spit a bunch of forward reference bugs.
Arguably it could be framed as poor modularity in the Phobos design.
A specific problem with templates is that in order to get a "duck type"
you pull the whole innards of module.
That's why I see that duck types could and should be peeled off from
modules.
What are you actually worried about? Compile times? Program size?
Startup time?
It affects all of it.
First and furthermost unnecessary and unavoidable junk that resides in
your program. Unnecessary "fake" dependencies on stuff your module
doesn't need. In the end with current setting a single touch of say
std.file pulls in a measurable amount of stuff (including ctors/dtors
that are run at startup/shutdown) you never wanted.
Is compile time a problem?
For libraries modularity and minimal dependencies are corner stones of
good design. I'd throw among these flexibility and pay and as go
principle as other key concerns.
The fact that D compiles fast can always be undermined by the way we
structure the code and dependencies.
Program size should be handled by the compiler. It is much better at
pruning dead code.
In case it know the code is dead. Throwing bunch of stuff at it that is
actually interdependent (the way it's written) doesn't help. The fact
that a lot of it is truly independent bears no relation to it partially
because of the compilation model.
Startup time should be handled by the modules themselves. For example,
std.random could initialize the global RNG only on demand.
Doesn't help to have gobla data for it. Not to say that the said dead
code for lazy initialization would pulled in always. And the other guy
that needs global PRGN now has to go through a "is-it-inited-yet" hook
_always_. You suggestion is a net loose on both counts then.
To summarize your point - you don't care and/or don't see it as a
problem. That's fine but and it then it just doesn't affect you in any way.
For Phobos developers to work a bit harder to design a cleaner
dependency chain so that you code loads less junk is a net gain.
All of that should concern Phobos guys and library writers.
Another question - did you ever read C run-time sources? They are
carefully modularized "by hand" so that if you want say printf you get
only what you truly need for it.
We currently do a very bad job at this kind of thing and it's not
entirely the compiler's fault.
--
Dmitry Olshansky
