Possible @property compromise

[Jonathan M Davis]

On Wednesday, January 30, 2013 15:26:32 1100110 wrote:
> On 01/30/2013 09:10 AM, Jacob Carlborg wrote:
> > On 2013-01-30 02:40, TommiT wrote:
> >> I always thought that having public member variables is a bad style of
> >> programming because of the lack of encapsulation. So, if there's a
> >> language feature that enables you to write public member variables, and
> >> later on, replace them with property functions, wouldn't that mean that
> >> the language is encouraging this particular kind of bad style of
> >> programming?
> > 
> > I really don't see much point in properties/methods that just forwards
> > to an instance variable.
> 
> Me either.
> 
> I mean yes, for anything that is part of a public api you should
> probably double check everything. But insisting on getters and setters
> regardless of the requirements of what you are getting and setting?
> 
> Sounds like an excuse to not think, to me.

The main reason for it is that you can add additional code later when it no 
longer needs to just get or set the variable. But one of the goals of 
properties is to make it so that you can just make it a public variable to 
begin with and then swap it out with a property function later when you need 
to add code like that. However, that never quite seems to work perfectly, as 
there's always something that you can do with a variable that you can't do 
with a property function (e.g. take its address or pass it by ref). Without 
properties though, you definitely want the getters and setters so that you 
don't lock yourself out of being able to properly protect the variable when 
you actually need to later.

- Jonathan m Davis