Lars Ivar Igesund wrote:
Don wrote:
John Reimer wrote:
Hello Johan,
As a user of D primarily and of the standard libraries secondly I see
this reluctance to solve the library situation as the single biggest
threat to D. It creates a division in the community and an uncertainty
of which library to base my own libraries on. If I use one and the
other wins the competition I have to redo a lot of work. It's also a
headache when distributing code as I don't know which functions and
packages I can assume exists.
I hear you. But the argument against this would probably be that you
would not have to redo all your work... you just start integrating the
use of the other (more popular) library in your work (since they have
common runtimes). While this is convenient, yet it would seem to be
cumbersome. Now projects will have dependencies on both full libraries
including the libary that falls from favour (if that in fact happens).
On the other hand, it wouldn't be so bad if one of Tango or Phobos
became a 3rd-party/extension library (more suitably this should be
Tango), in which case it would seem more natural and familiar to use it
as an addon to the other library.
-JJR
The other option (which I would prefer) is for druntime to get bigger,
and encompass more of the common code from both. So that both Phobos and
Tango became (crucial) extension libraries over a small core. And the
bigger that common core becomes, the smaller the library problem becomes.
druntime should certainly not become any bigger (in scope), as that would
defeat the purpose of separating the runtime from userspace in the first place.
The topic of common userspace functionality should be kept separate from the
topic of druntime.
I think you are confusing druntime (the project) with the D runtime.
druntime includes the gc as well the runtime, though they are seperate.
I see no reason why including core modules in the druntime project would
destroy the seperation.
Really, this is entirely a question of naming.
core.XXX seems to me to be the perfect namespace, certainly for the key
math modules which I'm most concerned about (std.math/(tango.math.Math,
tango.math.IEEE), and possibly also the low-level bigint routines. These
are all functionality which is closely tied to the compiler).
