Possible @property compromise

[Adam Wilson]

On Tue, 29 Jan 2013 17:40:45 -0800, TommiT <tommitissari at hotmail.com>  
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?

Not really, public fields ARE bad, but properties allow you to sanitize  
the data and throw exceptions if the data doesn't fit the spec. A field  
does not. In this way encapsulation is maintained.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/