Any chance to call Tango as Extended Standard Library

[Don]

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.