Wow, I didn't expect to have my first post here in this fashion, but:
I did it mainly because:
- I didn't like the previous conventions anymore
- it's closer to the current global trend
- it makes functions like begin(), clear(), etc. compatible with std notation
- it allows a less verbose and globally nicer syntax
Most of the reasons are lousy. In detail:
"- I didn't like the previous conventions anymore"The only sane reason. So you consider something that you have always been against better than something you didn't like? :roll:
"- it's closer to the current global trend"By "the current global trend" you mean the more confusing javaCase and Get-/Is- omission? But look, you hear they talking about something like "HTML5 is taking over ground and will dominate the industry and thus HTML5 IS THE FUTURE and the world is moving towards it" so it is HTML5 that is "the global trend", isn't it? If so, why not modify the lib for HTML5?
Oh, were they also talking about something like "JVM/.Net/Ajax/<INSERT_RANDOM_TECH_HYPE> IS THE FUTURE"? Never mind. :twisted:
"- it makes functions like begin(), clear(), etc. compatible with std notation"Are they compatible with std usage? If not, why should they impersonate something just different? And again, this javaCase != the dreaded lower_case naming convention that std uses, so that's not a success. :wink:
"- it allows a less verbose and globally nicer syntax"How could changes in the naming convention affect the syntax? You don't mean to use some grotesque C preprocessor # macro tricks for an alternative syntax, do you? :shock:
Seriously, there is a reason (might seem weak but still standing) for me to oppse the javaCase + omitted-Get-/Is- notation for functions:
class A
{
public:
// camelCase + omitting Get-
int publicProperty0;
int &publicProperty1() { return m_value1; }
int publicProperty2;
// PascalCase and I actually like it for function naming
int &GetPublicProperty1() { return m_value1; }
int GetPublicPropertyCount() { return 3;}
private:
int m_value1;
};
void foo()
{
using namespace std;
A someVar; // I always use camelCase for variable names
cout << someVar.publicProperty0 << endl;
cout << someVar.publicProperty1 << endl; // SYNTAX ERROR thanks to misleading name
cout << someVar.publicProperty1() << endl; // OK but inconsistent syntax
cout << someVar.publicProperty2 << endl;
cout << someVar.GetPublicProperty1() << endl; // OK
cout << someVar.GetPublicPropertyCount() << endl; // OK and consistent
}
class B
{
public:
bool empty(); // Is- omitted, so guess what this does - remember STL's similar flaw?
bool Empty() { return m_container.remove_all_elements() == SUCCESS_OK; } // you see?
bool IsEmpty() { return m_container.count_elements() == 0; }
private:
SomeContainer m_container;
};
As you may see, since C++ doesn't support C#-ish properies, it has to use member functions whose invoking syntax is different from C#-ish properties', and trying to mimic that
imperfectly may lead to syntax (class A example) and sematic (class B example) errors. Further more, AFAIK, many C++ coding standards require that every function name should contain a verb. So I don't think this naming convention change (except that of class internal members) is the right move.
Still, it's good to know that SFML 2.0 has finally been finished (or close to finished if you are going to change the naming convention again after reading this post). Good job!
