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. >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