3 ms·

I don't write C# but I also dislike this notation in C++. If I want to make it obvious that I'm accessing a member then I write "this->member". IMO it was a mi

by simias 8y ago

I don't write C# but I also dislike this notation in C++. If I want to make it obvious that I'm accessing a member then I write "this->member". IMO it was a mistake for C++ to allow the "this" to be implied for members, it makes it a lot harder to figure out what C++ code is doing and what's dealing with member variables and methods vs. globals. At the same time "m_" prefix only solves half of the problem because it doesn't help with method calls. That's why I prefer to drop the 'm_' and just put the "this->" everywhere, even when it's not mandatory.

72deluxe 8y ago
But what the method resolves to could be very different in the case of an inherited hierarchy, or where a base function is overridden in a child class. It has never been a difficulty even with colossal codebases that the function that it is resolved to might be elsewhere, in a child. If anything, it's one of the great strengths of the language. The m_ syntax is kind of ugly but adding a this-> every time seems foolish, given that either the member is protected or public if you're modifying it in a base class. In the case of complex inheritance, you might be running into problems with ambiguity of names anyway. m_variable (or a sensible member naming convention, e.g. a prefix) helps to distinguish between local variables, which is important in complicated classes/functions. This proposed # for JavaScript looks insane, coming from the well-established, tried, and tested (and perfectly functional and useful) systems found in C++, Java and C#. It's like it's adopting a terrible syntax in order to solve a problem that doesn't exist. Perhaps I am misunderstanding.