New naming convention

[Laurent]

Hopefully that is not the only reason? Even though a lot of people (including myself) seem to be getting their wish in this matter, I think you should only do it if you feel it is the best option for SFML, in the long run.

Of course, camelCase is also my personal choice.

Maybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.

I don't think people need a release to know which naming convention they prefer. They can write a sample code themselves if they really need to see it in action.
And I don't want to commit this modification until I'm 100% sure that it's the final one. Imagine people who start to convert all their code, and suddenly I go back to the original naming convention...

[Dravere]

@Mikademus,
Name me a language where threading is part of the language. Where date and time is part of the language. Where I/O is part of the language. Containers are part of the language. You can use C++ without using the standard library. The standard library (btw. isn't the same as STL) isn't a part of the language! It is a library like Boost too. I have no knowledge of a language that has all the functionality of Boost implemented in the language itself. Your argument simply makes no sense at all.

And apart from that: Why is it important that I know that a given class is coming from the standard library or boost? Why do I need that knowledge while reading some code? And don't I already have it through the use of std:: or boost:: ?

It is normal that unique styles and conventions evolve around the language symbols, and claiming that userland code must or should stay as close to the "language style" as possible is unacceptably restrictive and potentially damaging.

Name some example. I don't see this in lua, python, c#, java, etc.
There is only one place where this is happening: C++. Because the people don't like camel_case.

..., the most pedagogical and ergonomic being camelCase.

Is there any evidence except from your personal preference? Why is C# using PascalCase and the majority of the libraries in C# are using PascalCase? If camelCase would be that much better, they would have switched or at least the userbase would have switched.

Why are the boost people using camel_case? To be consistent with the standard library. And boost isn't part of the language!

In sum: It is a move for consistency, pedagogics and ergonomics to move SFML to camelCase. Using camelCase is not being inconsistent with the language itself.

It has nothing to do with consistency, pedagogics or ergonomics. There is no evidence for this. It is only personal preference.


But it seems Laurent made his choice already. Lucky me I haven't changed to use SFML 2.0 yet

Imagine people who start to convert all their code, and suddenly I go back to the original naming convention...

Well it is an unstable API :lol:

[BMB]

Maybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.

I don't think people need a release to know which naming convention they prefer. They can write a sample code themselves if they really need to see it in action.
And I don't want to commit this modification until I'm 100% sure that it's the final one. Imagine people who start to convert all their code, and suddenly I go back to the original naming convention...

Myself, I have not tested any changes committed since this discussion started, since I feel it is silly to check out and use a new version, just to have my code break. I am waiting for this naming change to be committed before I do another pull and use the latest source. I assume I am not alone in this. This seems to me to be a good reson to do a commit, even if you are only 95% sure.

[tobybear]

Maybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.

I don't think people need a release to know which naming convention they prefer. They can write a sample code themselves if they really need to see it in action.
And I don't want to commit this modification until I'm 100% sure that it's the final one. Imagine people who start to convert all their code, and suddenly I go back to the original naming convention...

Myself, I have not tested any changes committed since this discussion started, since I feel it is silly to check out and use a new version, just to have my code break. I am waiting for this naming change to be committed before I do another pull and use the latest source. I assume I am not alone in this. This seems to me to be a good reson to do a commit, even if you are only 95% sure.

Yeah, right. Go, Laurent, go! We want SFML2! :-)

[Laurent]

I'm currently busy updating the C and .Net bindings (there's still using the old graphics API), and then I'll be able to push the new naming convention.

[Silvah]

Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).

Well, if I can wish: proper and standard (i.e. American) spelling; f.i. color (correct) as opposed to colour (incorrect).  :twisted:

[OniLinkPlus]

Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).

Well, if I can wish: proper and standard (i.e. American) spelling; f.i. color (correct) as opposed to colour (incorrect).  :twisted:

Well, let's not start a debate here, but do you know why it's called English? Because it came from England/Britain. In other words, Britain's spelling is correct, as it is their language.

[pdinklag]

So what else do people want?

Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).

With all due respect to British English, from what I've seen in many years, the standard language in programming is U.S. English. I don't want to bring up a debate about how the Americans butchered the English language, but it's a fact that a simple modification like "color" to "colour" makes it a lot easier to type and read (especially for those whose native language is not English).

Name me a language where threading is part of the language.

Java.

Why is C# using PascalCase and the majority of the libraries in C# are using PascalCase? If camelCase would be that much better, they would have switched or at least the userbase would have switched.

Let me turn that around: why does the Java naming convention explicitly endorse camelCase and every Java library follows it? If it was that bad, they would have switched...

You can argue about this topic all day. It's probably the best thing to go with the majority (and I'm not saying this because I'm part of it - I honestly couldn't care less since I am writing a Java binding that uses camelCase anyway).

And boost isn't part of the language!

Is boost not an official part of C++11? Or, at least, officially endorsed?

[Nexus]

Seems like I have to abandon the field, the other advocates of PascalCase already did that long ago

I wouldn't care about the API break so much, if only I saw a real advantage in the modification, as it would be the case for the Qt convention. Now it looks to me that the whole modification is quite arbitrary and based only on personal preference. As a library developer you can do that, of course, but... I hope you never change your preference again

[Nexus]

Name me a language where threading is part of the language.

Java.

It's not completely part of the language, you also need the standard library for the Thread class. In fact, in Java you need the standard library far more often (if not always) than in C++, because as a result of the Object base class, everything is extremely coupled.

Is boost not an official part of C++11? Or, at least, officially endorsed?

No, some parts of Boost are taken into the standard library, but Boost remains an external library.

[Ceylo]

I wouldn't care about the API break so much, if only I saw a real advantage in the modification, as it would be the case for the Qt convention.

Well.. advantages have been given in the previous posts, don't they seem valid to you?

[pdinklag]

Name me a language where threading is part of the language.

Java.

It's not completely part of the language, you also need the standard library for the Thread class. In fact, in Java you need the standard library far more often (if not always) than in C++, because as a result of the Object base class, everything is extremely coupled.

Well, for instance, "synchronized" is a Java keyword, it's part of the language specification, and it's solely related to threading. The Java "standard library" essentially is Java. If you take away this library, you are dealing with nothing but the JVM itself. After all, even the "primitive types" (int, float, etc.) are actually just boxed versions of classes in the "java.lang" package, which also contains "Object" itself.

Is boost not an official part of C++11? Or, at least, officially endorsed?

No, some parts of Boost are taken into the standard library, but Boost remains an external library.

OK, good to know.
I can't keep track of all those C++0x / C++11 developments. I'm not even sure whether anyone really cares...

[Mikademus]

Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).

Well, if I can wish: proper and standard (i.e. American) spelling; f.i. color (correct) as opposed to colour (incorrect).  :twisted:

There is no such thing as "American English" (it is a colloquialism--or vulgarism depending on your degree of lenience--albeit a ubiquitous one), but there is an US American dialect of English. Admittedly, there is no official "Standard English", but the expression is universally (well, worldwide, at least) accepted as referring to the modern British usage, which just because of that isn't called a "dialect", or at least the "root dialect" of its derivatives.

Unfortunately, you already have your wish, since SFML is using US spelling atm (why I have no idea since Laurent is French, and they learn British spelling in schools, iirc), so it was rather a dull request.

That said, if you want to I will happily concede to the expression "Abominable English" for the US bastardisation of the source language.

Enough banter; have fun flaming this post, any Yanks that feel indignation or slighted.

[model76]

That said, if you want to I will happily concede to the expression "Abominable English" for the US bastardisation of the source language.

What exactly are you trying to achieve with these insults?
Is there a good reason for this behavior, or if not, will you please stop?

[Nexus]

Well.. advantages have been given in the previous posts, don't they seem valid to you?

More widespread use... It may make more people happy, which I understand (however keep in mind that opinions in this thread needn't be representative for the whole SFML community). But I consider the fact that I don't have to press shift rather irrelevant, since I read code more often than I write it, and I use auto-completion tools.

Anyway, I think that's been discussed enough now