26-Apr-2013 07:23, Jonathan M Davis пишет:
On Wednesday, April 24, 2013 16:03:47 Dmitry Olshansky wrote:
What we need is to re-arrange the module hierarchy (and we need that
anyway) so that we split off the "concept" part of modules to a separate
package.
Thoughts? Other ideas?
I'm a bit divided on the idea. On the one hand, it allows us to reduce
interdependencies. On the other hand, it's definitely complicating the module
hierarchy. This whole idea is a bit like the .h/.cpp or .di/.d separation.
In general what I propose is a special case of reducing artificial
dependencies due to coarse-grained modularization.
Now C had a crude mechanism for hiding details and achieving
modularization, we have proper modules (and OT: awful visibility rules).
On
the whole, I prefer the model of shoving it all in one file, but given that
Phobos is the standard library (of a _systems_ language no less), the added
complication may very well be worth the benefits in dependency reduction.
Yup.
Still, given that we're talking about templates here, most of it shouldn't end
up in the generated executable or library if it's not used, and we've already
been moving away from static constructors in Phobos, and global/module level
variables should already be quite rare.
Still not the case, hence the proposal. In general there are globals
(and TLS) and they are useful in their own right and there is nothing
better when you need that functionality.
And once Phobos is a shared library,
the few global/module level variables we have should cost even less.
False - the cost is _always_ there as dynamic linker still has to pull
that stuff off disk and run ctors/dtors.
The only gain is that running multiple D binaries linked against the
same phobos will share its code in memory. That and the "binaries look
small" argument :)
If D was the default systems language on some platform (like C does) it
would also mean having run-time always there (thus you wouldn't have to
ship it).
So, I'm
not sure that the extra complication is really worth it. If the compiler and
linker are doing their job, the only real difference should be in how much the
various modules in Phobos need to be parsed, which is very fast with dmd, and
most programs of any size are going to pull in all of the dependencies anyway.
Have you read the description? I gave the exact cases where regardless
of templates or no templates you do pull in the module. This is a
problem that defeat the whole goodness of generating only the code you
use (via templates). In fact I'll post about more specific problem
separately (need to gather the solid data).
And I would question the "most programs of any size are going to pull in
all of the dependencies anyway". All programs are different. And I'm
more concerned with Phobos itself and libraries.
The proverbial sufficiently smart compiler that trims down things to
establish true per symbol dependency may never come (unless we change
compilation model at the same time)
I'm inclined to avoid doing this if we don't really need to, but if there's a
solid benefit to it, then it may be that we really should do something like
this.
Would have to show it then. One such benefit may as well be being able
to avoid forward reference hell with the current compiler. Fake circular
dependencies is the 2nd one.
Thinking more of it - the idea would have been neat and elegant with a
variation on DIP 15. Then std.xyz.trait would be the trait part of a
package.
http://wiki.dlang.org/DIP15
On a side note, given that we sometimes call eponymous templates like
isForwardRange traits, calling the sub-module trait or traits rather than
concepts might be better (probably std.trait given that std.traits is already
taken, though that would probably then become std.trait.traits given that it's
entirely made up of traits).
Yeah, I thought as much. Concept has no established usage in D culture,
so trait it is.
--
Dmitry Olshansky
