Possible @property compromise

[H. S. Teoh]

On Wed, Jan 30, 2013 at 02:40:45AM +0100, TommiT wrote:
> On Wednesday, 30 January 2013 at 00:25:41 UTC, Jonathan M Davis
> wrote:
> >On Wednesday, January 30, 2013 00:55:13 Rob T wrote:
> >>[..]
> >>You know a lot more about implementing compiler magic than I do,
> >>so I'll ask you if you think the effort is doable enough
> >>to justify having property functions that can act like a
> >>drop in replacement for existing variables?
> >
> >I believe that two main things are needed: [..]
> 
> 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?

Property functions are precisely what gives you encapsulation.

Think about it. They let you "pretend" that there's a public member
variable, but actually you don't know (and don't have to know) what
their real implementation is. This is, by definition, encapsulation.
So this is actually an argument *for*, rather than against, property
functions.

There's nothing wrong with public member variables per se, it's the fact
that it makes external code rely on their specific implementation.
Property functions alleviate this problem by making it possible to
change the underlying implementation without needing to touch user code.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis