Possible @property compromise

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Jan 29 20:22:28 PST 2013


On 1/29/13 8:40 PM, 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?

The thing here is that properties offer control over changing the 
variable, which makes all the difference.

Andrei


More information about the Digitalmars-d mailing list