Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
IUnknown wrote:
Regarding Phobos + Tango, the minimum I expect is things like
containers, algorithm and common math stuff to be in one core module.
This is already bound to be an issue because there is disagreement
on how e.g. containers should look like (Java-style vs. STL-style).
Which should be chosen? This naturally influences how algorithms
are defined.
Andrei
The analogy with KDE vs Gnome doesn't seem valid to me -- most
libraries will work regardless of which GUI library is chosen.
Programmers can still rely on the Posix and C standard libraries.
I agree.
Can we work out the math stuff at least? There's no difference
between Phobos and Tango there. All we need is an agreement on
common module naming (eg, create core.math).
That would be great. I don't think that's a major issue anyway. If I
were you, to be compatible with today's state of affairs, I'd simply
put in the makefile the code necessary for switching the module
prefixes.
It means that any code which uses a library based on both Tango and a
library based on Phobos will end up with two copies of all of the
functions, and they'll have different name mangling etc. You end up
with two incompatible Bigints, for example, even though they have
identical code inside.
Oh, I see. You want your library to be usable whether the end user
prefers Phobos or Tango. But then why not stick it into a namespace of
your choosing? Let's say your libraries are general enough to warrant
putting them in a common core, but then anyone who defines some library
don't have to go to the "core ombudsman" to add it to the common
namespace. They'd just create unique namespaces of their own. No?
That's possible too. Originally, my code was in the 'mathextra'
namespace, and I'm somewhat regretting moving it it out.
You still need an ombudsman, though, to determine which libraries are
standard, and which are not, in order to prevent namespace collisions.
Personally, I like the boost model -- all you need is a root level (like
'boost') to act as a namespace protection mechanism, and then a library
standardisation policy.
But then you have the question as to the organisation of the 'std'
namespace -- for example, it contains such obscure stuff as std.openrj
which is actually a stand-alone library.
(I notice Dennis has just posted some similar sentiments, so I'll stop
for now).
It could be that all that we need is to create a standard naming policy.
