Hello .NET, D Here Calling

[Nick Sabalausky]

"Daniel de Kok" <me at nowhere.nospam> wrote in message 
news:girn6u$2sn4$1 at digitalmars.com...
> On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a at a.a> said:
>> It's far more than a mere presumption:
>>
>> class Foo{
>>   public int x;
>> }
>>
>> // vs
>>
>> class Foo{
>>   private int _x;
>>   public int getX() {
>>       return x;
>>   }
>>   public void setX(int x) {
>>       _x = x;
>>   }
>> }
>>
>> It would take a Java mentality to find the second to be every bit as good 
>> as
>> the first. Yes, it's functionally equivilent, but it's a horrid mess
>
> I happen to disagree :^).
>
>> provides absolutely no benefit in a language that supports properties. 
>> Note
>> also, that the second form provides absolutely no more encapsulation
>> benefits than the first.
>
> It *does* provide more encapsulation, since you could modify the getter or 
> setter without changes for the called. This was supposed to be one of the 
> advantages of encapsulation (and it is).
>

How is that any different from the first form (in a language that supports 
properties)? Like I've been saying, with properties, you *can* change 
"public int x;" into any form of getters/setters without any changes for the 
caller. That's one of the main points of properties. So as long as a 
language supports properties, the encapsulation is exactly the same. The 
idea that "public int x;" has less encapsulation is *only* true when a 
language doesn't support properties.