On Saturday, 7 December 2013 at 00:09:01 UTC, John Colvin wrote:
On Friday, 6 December 2013 at 23:56:39 UTC, H. S. Teoh wrote:
It would be nice to decouple Phobos modules more. A *lot* more.
Why? I've seen this point made several times and I can't
understand why this is an important concern.
I see the interplay between phobos modules as good, it saves
reinventing the wheel all over the place, making for a smaller,
cleaner standard library.
Am I missing something fundamental here?
On the introduction page of the Phobos documentation, as part of
it's philosophy, it states
"Classes should strive to be independent of one another
It's discouraging to pull in a megabyte of code bloat by just
trying to read a file into an array of bytes. Class independence
also means that classes that turn out to be mistakes can be
deprecated and redesigned without forcing a rewrite of the rest
of the class library."
(This can also apply to functions, templates and modules).
Currently, Phobos does exactly that. It pulls in a lot of bloat
to perform trivial tasks, and it is discouraging. More
importantly it is difficult to isolate any part of Phobos. When
trying to avoid any part of Phobos because of bugginess or
inefficiency, I find it next to impossible because chances are,
it will be used by some other part of Phobos.
I am speculating here, but I imagine that maintaining and
debugging Phobos must be a nightmare. Can anybody speak from
experience on this?
One think I have discovered is that Phobos introduces "junk code"
into executables. One time I did an experiment. I copied the bits
of Phobos that my program used into a separate file and imported
that instead of the Phobos modules. The resultant executable was
half the size (using -release, -inline, -O and "strip" in both
cases). For some reason, Phobos was adding over 250KB of junk
code that strip could not get rid of.
Regards
Jason
