Andrei Alexandrescu wrote:
Lars Ivar Igesund wrote:
Sean Kelly wrote:
Don wrote:
We also now have two modules called 'bitmanip', which is somewhat
ironic
since we brainstormed for ages trying to come up with a better name for
it. Modules with duplicate names have caused linking problems in the
past -- not sure if that applies here.
It applies if the modules from both Phobos and druntime end up in the
same library on *nix. Windows doesn't appear to have the same issue.
But I'd love to hear suggestions for alternative names-- I'm not
terribly good at naming modules :-p.
Also, any I'd like to see how people feel about having three top-level
packages in druntime vs. one-- an alternative I'd considered was to put
everything under core.
Sean
Functionality exposed from the runtime should reside in core, std
shouldn't
be used in druntime and any other packages (sys) is presumingly reserved
for what corresponds to tango.sys
In any case, a hierarchy of the type
common/
core/
sys/
stdc/
should be highly considered. This would allow a namespace for
functionality
that is truly common, not only the runtime, but math and eventually other
functionality. In addition it is naive to believe that just because
druntime is meant to be a common runtime, that it will be the only
runtime
in the long run.
A problem I see with the proliferation of top-level packages in the
standard library is that each of them makes homonym user-defined
packages inaccessible. Heck, I have a package called "common" today.
Andrei
'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why
stdc couldn't be part of 'sys'?
IMHO: 'common' sounds far too generic. 'core' is borderline.
Of course if the non-common parts of Phobos were moved to a namespace
called 'phobos', std would become the perfect location for common code.
But changing std.stdio to phobos.stdio might not be acceptable.
Anyway, we need to arrange a common location somehow.
