On 12/28/2012 7:51 AM, Russel Winder wrote:
> On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
>> DMD is actually written in C++, Walter just chose file names
>> ending in .c for some strange reason.
>
> I can understand using C++ rather than C, but (sorry Walter) naming the
> files X.c is a f###### stupid idea. The standard name strategy is one of
> X.C, X.cc, or X.cpp, for very good reasons.
>

Yeah, the standard name is .C, or is it .cc, or is it .cpp, or is it .cxx (I've seen that "standard" one, too), and are headers .hxx or is the standard .hpp or whatever.

Hell, I've even seen .c++

It's about the most non-standard "standard" I've ever encountered :-)

On Friday, 28 December 2012 at 19:06:05 UTC, Walter Bright wrote:
> On 12/28/2012 7:51 AM, Russel Winder wrote:
>> On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
>>> DMD is actually written in C++, Walter just chose file names
>>> ending in .c for some strange reason.
>>
>> I can understand using C++ rather than C, but (sorry Walter) naming the
>> files X.c is a f###### stupid idea. The standard name strategy is one of
>> X.C, X.cc, or X.cpp, for very good reasons.
>>
>
> Yeah, the standard name is .C, or is it .cc, or is it .cpp, or is it .cxx (I've seen that "standard" one, too), and are headers .hxx or is the standard .hpp or whatever.
>
> Hell, I've even seen .c++
>
> It's about the most non-standard "standard" I've ever encountered :-)

I guess the convention is "Anything that is clear as to language the file contains".

".cpp" and ".cxx" are both very good at that. ".cc" is less good, ".C" is even worse. All of them are better than ".c"

On 12/28/12 1:34 PM, Jacob Carlborg wrote:
> On 2012-12-28 17:27, Andrei Alexandrescu wrote:
>
>> From the HSP (Holiday Spirit Police):
>>
>> s/f###### stupid/odd/
>
> I agree with Russel in this case.

I wasn't disagreeing.

Andrei

On 12/28/12 2:21 PM, John Colvin wrote:
> On Friday, 28 December 2012 at 19:06:05 UTC, Walter Bright wrote:
>> On 12/28/2012 7:51 AM, Russel Winder wrote:
>>> On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
>>>> DMD is actually written in C++, Walter just chose file names
>>>> ending in .c for some strange reason.
>>>
>>> I can understand using C++ rather than C, but (sorry Walter) naming the
>>> files X.c is a f###### stupid idea. The standard name strategy is one of
>>> X.C, X.cc, or X.cpp, for very good reasons.
>>>
>>
>> Yeah, the standard name is .C, or is it .cc, or is it .cpp, or is it
>> .cxx (I've seen that "standard" one, too), and are headers .hxx or is
>> the standard .hpp or whatever.
>>
>> Hell, I've even seen .c++
>>
>> It's about the most non-standard "standard" I've ever encountered :-)
>
> I guess the convention is "Anything that is clear as to language the
> file contains".
>
> ".cpp" and ".cxx" are both very good at that. ".cc" is less good, ".C"
> is even worse. All of them are better than ".c"

I wondered how much work it takes so I just created a fork that renames all relevant .c files to .cpp.

https://github.com/andralex/dmd/tree/extensions

Works on OSX just swell and took me little more than 5 minutes. Anyone wants to take that over and make it work for Windows too?


Andrei

On Fri, 28 Dec 2012, Andrei Alexandrescu wrote:

> On 12/28/12 2:21 PM, John Colvin wrote:
> > On Friday, 28 December 2012 at 19:06:05 UTC, Walter Bright wrote:
> > > On 12/28/2012 7:51 AM, Russel Winder wrote:
> > > > On Fri, 2012-12-28 at 16:30 +0100, David Nadlinger wrote:
> > > > > DMD is actually written in C++, Walter just chose file names ending in .c for some strange reason.
> > > > 
> > > > I can understand using C++ rather than C, but (sorry Walter) naming the files X.c is a f###### stupid idea. The standard name strategy is one of X.C, X.cc, or X.cpp, for very good reasons.
> > > > 
> > > 
> > > Yeah, the standard name is .C, or is it .cc, or is it .cpp, or is it .cxx (I've seen that "standard" one, too), and are headers .hxx or is the standard .hpp or whatever.
> > > 
> > > Hell, I've even seen .c++
> > > 
> > > It's about the most non-standard "standard" I've ever encountered :-)
> > 
> > I guess the convention is "Anything that is clear as to language the file contains".
> > 
> > ".cpp" and ".cxx" are both very good at that. ".cc" is less good, ".C" is even worse. All of them are better than ".c"
> 
> I wondered how much work it takes so I just created a fork that renames all relevant .c files to .cpp.
> 
> https://github.com/andralex/dmd/tree/extensions
> 
> Works on OSX just swell and took me little more than 5 minutes. Anyone wants to take that over and make it work for Windows too?
> 
> 
> Andrei

What impact does this have on the open pull requests?  If it's going to suddenly break every one of them, then I think it's a particularly bad idea.  The benefit is debatable and the cost is pretty annoying.

On 12/28/12 4:39 PM, Brad Roberts wrote:
> What impact does this have on the open pull requests?  If it's going to
> suddenly break every one of them, then I think it's a particularly bad
> idea.

There are dozens of open pull requests and if worse comes to worst people will agree to fix their requests because the request for changing extensions has enjoyed considerable popularity.

> The benefit is debatable and the cost is pretty annoying.

The benefit is we'll avoid resurrecting a debate that comes back and again. Technically there's no reason to move with the change, but right now we're wasting time and burning through karma. Making the change shows respect for the community and for working together in an environment that has few gratuitous idiosyncrasies.

Let's do it.


Thanks,

Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:kbl3eh$2qe8$1@digitalmars.com...
> On 12/28/12 4:39 PM, Brad Roberts wrote:
>> What impact does this have on the open pull requests?  If it's going to suddenly break every one of them, then I think it's a particularly bad idea.
>
> There are dozens of open pull requests and if worse comes to worst people will agree to fix their requests because the request for changing extensions has enjoyed considerable popularity.
>
>> The benefit is debatable and the cost is pretty annoying.
>
> The benefit is we'll avoid resurrecting a debate that comes back and again. Technically there's no reason to move with the change, but right now we're wasting time and burning through karma. Making the change shows respect for the community and for working together in an environment that has few gratuitous idiosyncrasies.
>
> Let's do it.
>
>
> Thanks,
>
> Andrei

You want to screw up over a hundred open pull requests and destroy the commit history... for what?  Because every year or so someone complains about the file extensions?  Anyone that takes longer than 5 minutes to work out what's going on probably shouldn't be trying to change the compiler's build process.

Put a note in the readme, the makefile, and/or the wiki page on building the compiler, and leave the source alone.

Daniel.

On 29.12.2012 12:18, Daniel Murphy wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
> news:kbl3eh$2qe8$1@digitalmars.com...
>> On 12/28/12 4:39 PM, Brad Roberts wrote:
>>> What impact does this have on the open pull requests?  If it's going to
>>> suddenly break every one of them, then I think it's a particularly bad
>>> idea.
>>
>> There are dozens of open pull requests and if worse comes to worst people
>> will agree to fix their requests because the request for changing
>> extensions has enjoyed considerable popularity.
>>
>>> The benefit is debatable and the cost is pretty annoying.
>>
>> The benefit is we'll avoid resurrecting a debate that comes back and
>> again. Technically there's no reason to move with the change, but right
>> now we're wasting time and burning through karma. Making the change shows
>> respect for the community and for working together in an environment that
>> has few gratuitous idiosyncrasies.
>>
>> Let's do it.
>>
>>
>> Thanks,
>>
>> Andrei
>
> You want to screw up over a hundred open pull requests and destroy the
> commit history... for what?  Because every year or so someone complains
> about the file extensions?  Anyone that takes longer than 5 minutes to work
> out what's going on probably shouldn't be trying to change the compiler's
> build process.
>
> Put a note in the readme, the makefile, and/or the wiki page on building the
> compiler, and leave the source alone.
>
> Daniel.
>
>

Nobody answered the important question: does it "break" pull requests?

In my (limited) understanding git supports renames and pulls will be "broken" in the same way the are when there's a new commit on the original repo: people will just have to rebase their changes on it. I did some googling and found nobody complaining about this problem, so I assume there's some way to avoid it.

On Saturday, December 29, 2012 12:52:11 Marco Nembrini wrote:
> Nobody answered the important question: does it "break" pull requests?
> 
> In my (limited) understanding git supports renames and pulls will be "broken" in the same way the are when there's a new commit on the original repo: people will just have to rebase their changes on it. I did some googling and found nobody complaining about this problem, so I assume there's some way to avoid it.

I would expect rebasing to fix it trivially so long as git mv was used rather than renaming the file with the OS' commands, but I don't know for sure.

- Jonathan M Davis

On Saturday, 29 December 2012 at 02:11:03 UTC, Jonathan M Davis wrote:
> I would expect rebasing to fix it trivially so long as git mv was used rather
> than renaming the file with the OS' commands, but I don't know for sure.
>
> - Jonathan M Davis

IIRC, Git can figure out if a raw renamed file (a new file from git's
perspective) is a rename of an old file if the contents are the
same as a recently removed file above a certain threshold (70 percentish).

Considering the contents of the files shouldn't change at all, I
_think_ git should be able to figure out what's happened.


No idea what'll happen to the pull requests, though.