Darren New <dne### [at] sanrrcom> wrote:
> >> I don't have to guess. I read the code.
> > 
> >   Even a couple of years from now?

> Even after someone has gone and changed it from a global to a member 
> variable without updating all the names, yes. :-)

  You magically know from the name of the variable that someone changed its
scope?

> >>> (they may even be in a completely different file).
> > 
> >> You're probably doing it wrong if they're in a different file. Or you're 
> >> using a language that unnecessarily makes it necessary.
> > 
> >   At least you acknowledge that the member variable declarations may be
> > very far away from their usage, making it hard to connect the two while
> > casually browsing the code, because you didn't nitpick about that part.

> Yep. But with a decent language and/or IDE, it doesn't really matter how far 
> away the member variables are, or what file or superclass they're in. I 
> don't feel the need to have a naming convention help me harness the full 
> power of the language if the compiler already does that.

  As I said, you are just acknowleding that there *is* a problem in the
naming which has to be solved by using an IDE.

> >   A subclass cannot refer to a superclass' members because it has no access
> > to them. They are private.

> I fail to see how a superclass with all members private can be useful. 
> Unless you're using "member" to mean "instance variable" rather than 
> "instance function" or something.

  This whole thread has been about variables. Nobody has talked about
functions.

> >> Why is there even the concept of "protected" if a subclass 
> >> shouldn't refer to a superclass?
> > 
> >   You put member functions and abstract types there (for the derived class
> > to use).
> > 
> >   A member variable in the protected section is as bad as in the public one,
> > hence you don't put member variables in the protected section.

> Why?

  Because from the point of view of the derived class the member variable
is public, and thus with all the drawbacks.

> And what about member properties?

  Getter and setter functions are a separate issue. We are not talking
about member functions here. (Or at least I am not.)

> >> When you're using properties, that's what you're *supposed* to do. That's 
> >> what they're for.
> > 
> >   If the getter/setter of a member variable has the exact same name as the
> > member variable (which in itself is a braindead idea IMO), you can still
> > put a qualification in front of the call.

> It doesn't. But the syntax is that of a variable.

  If you want to use confusing syntax, that's up to you. ("Not only do not
I know if this is a local, global or member variable, I don't even know if
this is actually a property of this class or any of its base classes." Way
to add even more confusion.)

> I.e.,
>     x.a = 27;
> does not tell you whether "a" is a variable or a function in C#.

  Since classes don't have public member variables, it is a function (even
if the syntax is confusing). Haven't you learned already?

> >   Of course a getter/setter should not be named like the member variable
> > itself. Naming a member function mCounter is not a good idea because that
> > notation should be reserved for member variables, not member functions.

> What if you use variable syntax for getters and setters, just like C++ lets 
> you use array subscripting syntax for function calls?

  Getters and setters are member functions, not member variables, and hence
other naming conventions apply to them.

> If I have a string that's the title of the menu in a base class, and it's a 
> property that uses variable syntax, what should I name it and how would I 
> refer to it in the subclass?

  You use getter and setter functions, which are named with the proper naming
convention for member functions.

> >   Odd question. By calling a member function to set it up, of course.

> I *am* calling a member function to set it up. The member function is 
> invoked by me saying
>     Title = "Game Options";

  Well, if you deliberately want to make it ambiguous and confusing, that's
up to you. But remember that others may need to read and understand your
code. That "Title" doesn't make it at all obvious what it might be and
where it might be declared.

> >>> No member variables in the public (or protected) interface.
> > 
> >> What makes you think it's a variable?
> > 
> >   Because we are talking about the naming convention of member variables.
> > Member functions are a different story.

> And what exactly is the difference, theoretically speaking? Syntax? 
> Implementation? Future-proofing the code?

  Abstraction. A member variable is part of the internal implementation of
the class, while a public member function is part of its abstract public
interface which should usually reveal as little as possible about the
internal implementation details of the class.

> Is a getter/setter pair syntactically invoked like a variable and whose 
> underlying storage is inaccessible even to the class declaring the 
> setter/getter a member variable or a member function?

  I'd call it confusing.

> I know nothing in OOP that says exposing member variables that act like 
> variables is a bad idea. I know it's a bad idea in C++ and a few other 
> languages, and I know that some other languages (like Eiffel and C#) make it 
> not a bad idea. The worst that happens is if you change your mind you have 
> to recompile the code that uses it.

  Then maybe you should learn more about object-oriented programming
principles, then?

  If you expose a member variable, you are exposing an internal
implementation detail and thus making your class less abstract, making
it harder to modify later. Internal implementation details should be
hidden as well as possible so that changing these details becomes easier
without breaking the rest of the program.

  It's not a compiler-technical issue. It's an issue of program design.
It has nothing to do with a specific programming language.

> Indeed, having functions unassociated with classes and having global 
> variables at all is a much worse OOP design than having variables exposed in 
> the class interface.

  Well, usually you shouldn't have global variables in a well-designed
program. As for not having free functions, I don't quite get it. What's
wrong with having some convenience functions?

> >   It is a problem when you need the IDE in order to understand the program.

> But I don't. I can look up whether it's a global or not just fine without an 
> IDE. I don't feel the need to encode that into the names, is all.

  That's the problem: You have to "look it up". The name itself tells you
nothing. You have to study the rest of the code in order to understand what
the function is doing, and the name of the variable is giving you no hints
on where you might start looking.

  However, if you see from the name that it's eg. a member variable, then
there aren't many places you have to look for it.

  This becomes especially useful when there are dozens of different variables
being referred to in a function.

> >   Code readability should not rely on IDEs. It's precisely that reliance
> > that produces unreadable code which is hard to understand.

> I agree. However, I'm not depending on the IDE to make the code readable.

  Seemingly you are, given how much you advocate using an IDE to look up
variable definitions.

> >> I'm generally against redundancy in programs.
> > 
> >   Are you against readability?

> You're begging the question.

  I'm not. You are against redundancy. Are you also against redundancy when
it makes the code more readable?

> >> Adding things to the code that 
> >> the compiler can already provide for me is something that I find has always 
> >> been problematic.
> > 
> >   Having to resort to a compiler or IDE in order to understand a program is
> > a tell-tale sign that the program could have been written better.

> Having to resort to a naming convention to tell the reader what you already 
> told the reader is a tell-tale sign that the program could have been written 
> better too.

  Haha.

> Especially if you're going to assert that "mCounter" is always a member 
> variable of *this* class.

  If it isn't, then your program is badly designed and hard to understand.

> >   Take into account that maybe others will have to read your code, and they
> > might not have that fancy IDE at hand at the moment, yet they may have to
> > understand your code. Relying on IDEs for readability is a bad idea.

> I'm not relying on the IDE for readability.

  You are making contradictory statements. In one place you say that you
don't need any special naming conventions because you just use the IDE to
tell you where variables are defined, and here you are telling that you are
actually *not* using the IDE for readability.

> I'm having the IDE assist me in 
> easily finding the declaration of the variables I'm using. Whether it's a 
> member variable or a global variable is of much less interest than the type 
> of the variable, and I don't encode that into the name either.

  The type of the variable doesn't help you find its declaration. A naming
convention telling you where to look does.

-- 
                                                          - Warp

Post a reply to this message