Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualMatias Goldberg

Posted 10 November 2012 - 01:37 PM

The world would be so much easier if there were an extra keyword that is neither private or protected, which would mean that variables are read-only for inherited classes; therefore they can be read (like protected), but can't be modified (like private) without the need for getters. (Edit: And cannot be accessed at all by outsiders, like private & protected)

Whenever I write "getCount()" instead of mCount, it feels to me I'm doing "something" unless I have intelisense and see that getCount() is const. Regardless of seeing the 'get' prefix, the parenthesis just annoys me. It distracts me into thinking my function where I implement my algorithm is also performing other tasks inside it's inherited class instead of just feeding data required by my algorithm.
And what if getCount is not O(1)? I'd have to look at the source code, which cuts my productivity in analyzing functionality that may be totally irrelevant to what I'm writing (and sometimes the src is not available). By reading mCount, I don't have to worry that it's not O(1). If I don't see mCount but see getCount, then I know there might be a damn good reason it's like that. Probably because it can't be cached or the memory overhead is too big (i.e. working with millions of instances)

Of course, in some scenarios may happen that mCount is not up to date, and we have to call updateCount(); therefore getCount starts making more sense. Or if we insist in reading mCount because we know for sure it's up to date (and do it manually if we know it's not), then it means whatever I'm working on is performance intensive (i.e. updateCount is expensive, or may get called too often) and therefore I have to very well aware of the inner workings of the base class.
In this case, the inner working of the base class better be very well documented (which is a good thing IMHO).

Additionally, such keyword would solve the performance issue on compilers that can't inline getters well (including x86/x64 systems when running in debug mode. Don't complain if the build runs 40x slower)

I aknowledge all the reasons about private over protected. But I had to add my two cents because I was feeling that everyone's giving their opinion in favour of private, and seemingly not a single disadvantage or issue against it, as if there were none.

Cheers

#1Matias Goldberg

Posted 10 November 2012 - 12:14 PM

The world would be so much easier if there were an extra keyword that is neither private or protected, which would mean that variables are read-only for inherited classes; therefore they can be read (like protected), but can't be modified (like private) without the need for getters.

Whenever I write "getCount()" instead of mCount, it feels to me I'm doing "something" unless I have intelisense and see that getCount() is const. Regardless of seeing the 'get' prefix, the parenthesis just annoys me. It distracts me into thinking my function where I implement my algorithm is also performing other tasks inside it's inherited class instead of just feeding data required by my algorithm.
And what if getCount is not O(1)? I'd have to look at the source code, which cuts my productivity in analyzing functionality that may be totally irrelevant to what I'm writing (and sometimes the src is not available). By reading mCount, I don't have to worry that it's not O(1). If I don't see mCount but see getCount, then I know there might be a damn good reason it's like that. Probably because it can't be cached or the memory overhead is too big (i.e. working with millions of instances)

Of course, in some scenarios may happen that mCount is not up to date, and we have to call updateCount(); therefore getCount starts making more sense. Or if we insist in reading mCount because we know for sure it's up to date (and do it manually if we know it's not), then it means whatever I'm working on is performance intensive (i.e. updateCount is expensive, or may get called too often) and therefore I have to very well aware of the inner workings of the base class.
In this case, the inner working of the base class better be very well documented (which is a good thing IMHO).

Additionally, such keyword would solve the performance issue on compilers that can't inline getters well (including x86/x64 systems when running in debug mode. Don't complain if the build runs 40x slower)

I aknowledge all the reasons about private over protected. But I had to add my two cents because I was feeling that everyone's giving their opinion in favour of private, and seemingly not a single disadvantage or issue against it, as if there were none.

Cheers

PARTNERS