Daniel Keep wrote:
Andrei Alexandrescu wrote:
Don wrote:
[snip]
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?
Andrei
I think he means this: let's say you're writing app A. A depends on
libraries B and C. B depends on Phobos, and C depends on Tango. Both B
and C happen to use BigInts or IO or anything else that isn't shared.
All of a sudden, you've now got to link in TWO standard libraries
instead of just one, each with potentially duplicated code.
And you can't obtain a BigInt from library B and pass it into library C,
since they are different types; even though they have 100% identical
source code except for the name.
From personal experience, the alternative isn't much better: writing
code that switches between the two.
I have an XML library that can use either Phobos or Tango. It does this
by implementing all the calls it needs in a shim library, essentially
using it's own standard library.
It gets really fun when you need to implement some call that's trivial
in one library, but really hard in the other. I remember having to
build an IO layer so that both Phobos and Tango had the same semantics
regarding EOF or something...
Urgh.
-- Daniel
