On 2008-12-23 20:09:56 +0100, "Nick Sabalausky" <a@a.a> said:

> "Daniel de Kok" <me@nowhere.nospam> wrote in message
> news:gir3fq$1qjt$1@digitalmars.com...
>> I think that the D approach is good enough, since it does not add
>> complexity for library designers.
> 
> Library designers are exactly the people that properties are great for. They
> allow you to expose a "property" of a class in a way that can be changed
> back and forth between a variable and get/set functions without ever
> breaking a single line of the library user's code.

So can they do with getters and setters.

> For instance, suppose you're writing a class for "Paint", and you want the
> user to be able to choose and query the color. Sounds to me like a job for a
> variable. Set/get functions would be overkill.

Some would call it overkill, some would call it proper encapsulation. Personally, I never allow direct access to member variables (except for types that have no 'behavior'). It comes at virtually no extra cost, and there is a good chance that simple setters will require some validation or locking in the future anyway.

> So you change it to set/get functions and break everyone's code. "Gee, thanks".

That wouldn't happen, since I'd use getters/setters anyway ;). So far, the only advantage is the presumption that getters/setters are overkill.

> And then there's another reason:
> 
> foo.x += 7;
> 
> Is a hell of a lot nicer than
> 
> foo.setX(foo.getX + 7);

Maybe, but in the setter case you can explicitly see what is going on. Would you expect something that looks like a variable assignment to throw an exception or to perform validation?

Not that I religiously want to debate against properties, but I think C# has its amount of feature-creep, and I think this is one of the things one could easily do without. But then on the other hand, a lot of people are also happy with Java, which misses basic things like typedefs ;).

-- Daniel

Daniel de Kok:
> It comes at virtually no extra cost, and there is a good chance that simple setters will require some validation or locking in the future anyway.

It comes at no cost in Java, for example on the HotSpot JVM, and probably on dotnet too. But probably the current D compilers aren't that smart, and you have to pay a small cost (time) there. I don't know how LDC will do in such regard, probably about the same. (But it's a little cost that most of the times you are willing to pay in D too.)

Bye,
bearophile

"Daniel de Kok" <me@nowhere.nospam> wrote in message news:girh4b$2gss$1@digitalmars.com...
> On 2008-12-23 20:09:56 +0100, "Nick Sabalausky" <a@a.a> said:
>
>> "Daniel de Kok" <me@nowhere.nospam> wrote in message news:gir3fq$1qjt$1@digitalmars.com...
>>> I think that the D approach is good enough, since it does not add complexity for library designers.
>>
>> Library designers are exactly the people that properties are great for.
>> They
>> allow you to expose a "property" of a class in a way that can be changed
>> back and forth between a variable and get/set functions without ever
>> breaking a single line of the library user's code.
>
> So can they do with getters and setters.
>
>> For instance, suppose you're writing a class for "Paint", and you want
>> the
>> user to be able to choose and query the color. Sounds to me like a job
>> for a
>> variable. Set/get functions would be overkill.
>
> Some would call it overkill, some would call it proper encapsulation. Personally, I never allow direct access to member variables (except for types that have no 'behavior'). It comes at virtually no extra cost, and there is a good chance that simple setters will require some validation or locking in the future anyway.
>
>> So you change it to set/get functions and break everyone's code. "Gee, thanks".
>
> That wouldn't happen, since I'd use getters/setters anyway ;). So far, the only advantage is the presumption that getters/setters are overkill.
>

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 and 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. The only reason that idiom was ever created in the first place, and the only reason it's ever used (and the only reason public member variables were ever deemed to be bad style in the first place) is to provide an "upgrade path" in case more functionality is needed. Properties render that all irrelevant, and allow variables to once again be used for what they were actually intended for in the first place. (Also, they eliminate the need for getter/setter naming conventions.)

>> And then there's another reason:
>>
>> foo.x += 7;
>>
>> Is a hell of a lot nicer than
>>
>> foo.setX(foo.getX + 7);
>
> Maybe, but in the setter case you can explicitly see what is going on. Would you expect something that looks like a variable assignment to throw an exception or to perform validation?
>

Debatable, there are reasonable arguments on both sides (Personally, I find the latter to be a case of "mixing different levels of abstraction" and thus poor design for the same reason that not using functions is poor design: Implementation details *should* be abstracted away so they don't obscure the high-level concept of what you're doing. Take a look at the iterators and explicit (un)boxing in older versions of Java to see what a horrendous unreadable (and slow-to-develop) mess code becomes when you expect every line of code to be transparent.)

But regardless, if you're one of the many people that accept operator overloading, then the debate is moot: Operator overloading is every bit as capable of making what looks like a trivial operation do non-trivial things.

> Not that I religiously want to debate against properties, but I think C# has its amount of feature-creep, and I think this is one of the things one could easily do without. But then on the other hand, a lot of people are also happy with Java, which misses basic things like typedefs ;).
>
> -- Daniel
> 

On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a@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).

> But regardless, if you're one of the many people that accept operator
> overloading, then the debate is moot: Operator overloading is every bit as
> capable of making what looks like a trivial operation do non-trivial things.

I agree, and am not to fond of operator overloading. Of course, in C++ it is pretty much unavoidable for assignment and comparison. There is a place for operator overloading, e.g. in math labraries. But I don't like overuse of operator+ for, say, assigning widgets to some container, or operator* for string multiplication (as in Python).

But I guess there's also much taste involved, some people don't like verbosity ;).

-- Daniel

Daniel de Kok wrote:
> Maybe, but in the setter case you can explicitly see what is going on. Would you expect something that looks like a variable assignment to throw an exception or to perform validation?

If a field should be validated, I want it to be validated every time I assign to it. Otherwise I get an exception at some random time, and I have to do a lot of work in order to find out where I set a bad value.

"Daniel de Kok" <me@nowhere.nospam> wrote in message news:girn6u$2sn4$1@digitalmars.com...
> On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a@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.

Daniel de Kok wrote:
> On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a@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 :^).
> 

I suppose you're right.  The horribly twisted mind of a C++ coder could find that attractive as well.

On 2008-12-24 02:52:56 +0100, "Nick Sabalausky" <a@a.a> said:

> "Daniel de Kok" <me@nowhere.nospam> wrote in message
> news:girn6u$2sn4$1@digitalmars.com...
>> On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a@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)?

I am not saying it is different. I was just replying to your statement considering the example that the second form does not provide more encapsulation.

-- Daniel

Daniel de Kok Wrote:

> With no intention to flame, but I never quite understood why people are so keen on properties over getter/setter member functions. What advantage does it have over obscuring direct member access and indirect member access?

High level languages were invented to power programming with abstractions.