Possible @property compromise

[deadalnix]

On Wednesday, 30 January 2013 at 01:40:52 UTC, 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?

Belief is rarely a good thing.

public variable are an encapsulation problem if you don't have 
properties. Then, a bunch of boilerplate is written because in 1% 
of the cases, some logic will be hooked on the variable access.

Allowing properties allow the same level of encapsulation, 
without requiring boilerplate up-front.