3 ms·

Adding 8 comment lines doesn't help your argument. More importantly though, you need to consider the mental load of constantly thinking about and remembering wh

Adding 8 comment lines doesn't help your argument. More importantly though, you need to consider the mental load of constantly thinking about and remembering whether something is a property or a method. I used to be an advocate property syntax, but after seeing them used in C# and now in Swift I have completely changed my mind. It's an inconsistent mess that Java has avoided at the small price of some more lines of code (that are mostly auto generated and need no documentation)

int_19h 10y ago
Can you clarify what's inconsistent about properties in C# (seeing how this is the most obvious counterpart), and how it doesn't apply to Java's properties-by-convention?
- fauigerzigerk 10y ago
  In Java you can be reasonably sure that whenever you need something from an object you call a method of its class. That's one thing you rarely have to think about in practice. Yes there are exceptions (sometimes painfully inconsistent ones) where fields are accessed directly, but at least that gives you some performance guarantees. It's generally not a big concern. In C# you do have to think about it all the time. Most types have both properties and methods and in many cases it's not obvious whether the author of that type had the same idea about whether or not something should be a property or a method as you do. Where you only have to remember a name in Java, you have to remember both a name and its syntactic category in C#. One more thing to keep in mind equals greater mental load. In fact, the guidelines for choosing between one and the other include considerations that should be of no concern to the user of a public interface (https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100).aspx https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100)....). If any of these implementation details change, the logical conclusion would be to change the public interface from property syntax to method syntax or vice versa. That's what I call inconsistent. If you're saying that the choice between getX() and x() in Java is also somewhat inconsistent then you are absolutely right. It's just not a problem on the same scale as in C#.
  - breischl 10y ago
    I would argue that the distinction is actually a good thing. If you're working with a reasonably well-designed library, then the fact that something is a method instead of a property tells you it might be doing some serious (or just slow) work. Whereas in Java calling getX() might do just about anything. And if the implementation of a C# property changes in any of the ways that would make it a method, that probably deserves to be surfaced as a breaking change in the API. That's a feature, not a bug. eg, I would certainly want to know if the implementation of a property was changed from a field access to a network call.
    - fauigerzigerk 10y ago
      The syntactical distinction makes us believe that there is a technical difference as well, but that is not the case. I find that misleading. If properties don't give us any technical guarantees, then a naming convention as in Java seems more appropriate to me. And if you look at the guidelines I linked to, you'll see that the criteria that are supposed to tell us whether or not to use a property are much more subtle than making a network call vs accessing a field. Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property? I think disguising a function call as a direct variable access is much more problematic than calling a function that may or may not do more than return the value of a variable. That said, I do realize that reasonable people can absolutely disagree on this issue.
      - breischl 10y ago
        I think disguising a simple function call as a variable access is sensible. But yes, people can disagree on this. I think the C# and Java designers are probably all smart people who thought about this a lot more than the two of us. :) >>Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property? I just quickly re-read that page, but I don't see what you're referring to here.
        10y ago
- pjmlp 10y ago
  The worst case I tend to encounter across customer code is having properties with big bodies of several lines that should have been made proper methods in first place.

int_19h 10y ago

Can you clarify what's inconsistent about properties in C# (seeing how this is the most obvious counterpart), and how it doesn't apply to Java's properties-by-convention?

fauigerzigerk 10y ago
In Java you can be reasonably sure that whenever you need something from an object you call a method of its class. That's one thing you rarely have to think about in practice. Yes there are exceptions (sometimes painfully inconsistent ones) where fields are accessed directly, but at least that gives you some performance guarantees. It's generally not a big concern. In C# you do have to think about it all the time. Most types have both properties and methods and in many cases it's not obvious whether the author of that type had the same idea about whether or not something should be a property or a method as you do. Where you only have to remember a name in Java, you have to remember both a name and its syntactic category in C#. One more thing to keep in mind equals greater mental load. In fact, the guidelines for choosing between one and the other include considerations that should be of no concern to the user of a public interface (https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100).aspx https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100)....). If any of these implementation details change, the logical conclusion would be to change the public interface from property syntax to method syntax or vice versa. That's what I call inconsistent. If you're saying that the choice between getX() and x() in Java is also somewhat inconsistent then you are absolutely right. It's just not a problem on the same scale as in C#.
- breischl 10y ago
  I would argue that the distinction is actually a good thing. If you're working with a reasonably well-designed library, then the fact that something is a method instead of a property tells you it might be doing some serious (or just slow) work. Whereas in Java calling getX() might do just about anything. And if the implementation of a C# property changes in any of the ways that would make it a method, that probably deserves to be surfaced as a breaking change in the API. That's a feature, not a bug. eg, I would certainly want to know if the implementation of a property was changed from a field access to a network call.
  - fauigerzigerk 10y ago
    The syntactical distinction makes us believe that there is a technical difference as well, but that is not the case. I find that misleading. If properties don't give us any technical guarantees, then a naming convention as in Java seems more appropriate to me. And if you look at the guidelines I linked to, you'll see that the criteria that are supposed to tell us whether or not to use a property are much more subtle than making a network call vs accessing a field. Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property? I think disguising a function call as a direct variable access is much more problematic than calling a function that may or may not do more than return the value of a variable. That said, I do realize that reasonable people can absolutely disagree on this issue.
    - breischl 10y ago
      I think disguising a simple function call as a variable access is sensible. But yes, people can disagree on this. I think the C# and Java designers are probably all smart people who thought about this a lot more than the two of us. :) >>Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property? I just quickly re-read that page, but I don't see what you're referring to here.
      - 10y ago
pjmlp 10y ago
The worst case I tend to encounter across customer code is having properties with big bodies of several lines that should have been made proper methods in first place.