The path to unity [You ALL ignored my post!]

[Sean Kelly]

Andrei Alexandrescu wrote:
> Don wrote:
>> Piotrek wrote:
>>> Don pisze:
>>>> Don wrote:
>>>>> With the druntime project, we now have a run time which is shared 
>>>>> between Tango and Phobos. This is a huge step forward, but it's 
>>>>> still not much use without some common user code.
>>>>>
>>>>> The highest priorities which I see are, in order:
>>>>> (1) the C standard library
>>>>> tango.stdc = std.stdc
>>>>> (2) low-level compiler-related modules
>>>>> most of tango.core -- for the most part, this is already part of 
>>>>> druntime.
>>>>> (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().
>>>>>
>>>>> Can we get agreement on unification of these, at least?
>>>>>
>>>>> If we are able to reach agreement on this, I propose the next step 
>>>>> would be to ensure that the contents of these files be made 
>>>>> "identical" on Phobos2 and Tango. ("identical" meaning that when 
>>>>> the Tango code is ported to D2, it will be identical to the Phobos2 
>>>>> version, except for module name differences).
>>>>
>>>> Please read it again. I'm not asking the question "where do we put it?"
>>>> Rather, to agree that it WILL eventually go SOMEWHERE. If we agree 
>>>> on that, there are immediate implications. Those modules have some 
>>>> functions which differ in naming (mostly in case). That's a 
>>>> difference we can fix right now without the politics.
>>>
>>> I do agree it's a right direction to extract the common functionality 
>>> and put it in a one place. But it's a question to the Phobos and 
>>> Tango maintainers. After all, more time consuming efforts are needed.
>>
>> No, it's a question to the community. I'm the primary maintainer of 
>> the math modules in both libraries. The efforts are straightforwards 
>> and not very time consuming. But I don't think I can break code just 
>> because I have a personal desire for unity.
>>
>>> Indeed , I don't think there's a person who don't want to see it happen.
>>
>> Are people OK with some of their code breaking for the sake of unity?
>> For the math stuff, that would mean name changes on minor functions 
>> such as:
>> isnormal() -> isNormal()
>>
>> I need a mandate.

I'm in agreement.

> The convention I'd like to use for templates is the following: if the 
> template ultimately resolves in a type, e.g. BaseClassesTuple, start 
> with uppercase. If it resolves in a compile-time constant or a function, 
> e.g. hasAliasing, start with lowercase.

This is the convention I use as well, and I think it's a good one.


Sean