4 ms·

Interesting that this is seen as a negative, C# has getters/setters that look like property access, but I don’t think I ever heard anyone complain about this.

shp0ngle 3y ago
zig and c# each scratch a different itch.
- Semaphor 3y ago
  Yeah, of course. But the issue would still be the same in this case.
  - steveklabnik 3y ago
    While the issue is the same, context can make things different. In Ruby, I love proxy objects returned from accessors. In Rust, I wouldn't even support adding accessors to the language. Different goals and objectives.
int_19h 3y ago
C# inherited it from Delphi, so there's plenty of experience showing that this is not an issue in practice. Thing is, if you don't have accessor methods (or some equivalent syntactic sugar as in D) in a OO language, you end up with them anyway, just ad hoc like Java's get/set methods. And then you still have to think about which methods that look like they're pure queries might actually mutate shared state. If anything, I would argue that explicit accessors make it clearer because in e.g. C# you can't write a method that looks like a getter (but mutates state) by accidentally naming it as such. If someone made something a property, that's because they thought its semantics are property-like, which includes not mutating global state. Sure, people will still get that wrong occasionally, just as they run mutating "get" methods, but it is surprisingly rare.
- throwawaymaths 3y ago
  > because they thought its semantics are property-like, Suppose you include a logging statement in your accessor, which hides a race condition. You're gonna tear your hair out.
  - int_19h 3y ago
    Suppose you do the same in your getWhatever() method instead; what's the difference? If every property access is an explicit method call, the mental overhead on the API client is the same in practice, since most of those method calls are still semantically property-like and are treated as such.
- deleted 3y ago
  [deleted]
signaru 3y ago
C++ Builder also has them in their extensions to C++. My guess is that it looks convenient for languages that have a de facto GUI framework/library. In Delphi/Object Pascal, C#, C++ Builder, it becomes convenient to, for example, change a button's text as if assigning to its text value. And it is often taken for granted how the form's UI just "magically" updates. I'm pretty sure classic VB's control "properties" work that way as well. When I was new to their corresponding GUI frameworks, the dot + property notation was appealing because it looked clean. However, as I got more experienced I'm no longer seeing the advantage of saving two parentheses characters at the expense of potentially hiding function calls where anything can happen. I'm not sure why D joined the club given it doesn't have a corresponding de facto GUI framework, and its users even discourage it.

shp0ngle 3y ago

zig and c# each scratch a different itch.

Semaphor 3y ago
Yeah, of course. But the issue would still be the same in this case.
- steveklabnik 3y ago
  While the issue is the same, context can make things different. In Ruby, I love proxy objects returned from accessors. In Rust, I wouldn't even support adding accessors to the language. Different goals and objectives.

int_19h 3y ago

C# inherited it from Delphi, so there's plenty of experience showing that this is not an issue in practice. Thing is, if you don't have accessor methods (or some equivalent syntactic sugar as in D) in a OO language, you end up with them anyway, just ad hoc like Java's get/set methods. And then you still have to think about which methods that look like they're pure queries might actually mutate shared state. If anything, I would argue that explicit accessors make it clearer because in e.g. C# you can't write a method that looks like a getter (but mutates state) by accidentally naming it as such. If someone made something a property, that's because they thought its semantics are property-like, which includes not mutating global state. Sure, people will still get that wrong occasionally, just as they run mutating "get" methods, but it is surprisingly rare.

throwawaymaths 3y ago
> because they thought its semantics are property-like, Suppose you include a logging statement in your accessor, which hides a race condition. You're gonna tear your hair out.
- int_19h 3y ago
  Suppose you do the same in your getWhatever() method instead; what's the difference? If every property access is an explicit method call, the mental overhead on the API client is the same in practice, since most of those method calls are still semantically property-like and are treated as such.
deleted 3y ago
[deleted]

signaru 3y ago

C++ Builder also has them in their extensions to C++. My guess is that it looks convenient for languages that have a de facto GUI framework/library. In Delphi/Object Pascal, C#, C++ Builder, it becomes convenient to, for example, change a button's text as if assigning to its text value. And it is often taken for granted how the form's UI just "magically" updates. I'm pretty sure classic VB's control "properties" work that way as well. When I was new to their corresponding GUI frameworks, the dot + property notation was appealing because it looked clean. However, as I got more experienced I'm no longer seeing the advantage of saving two parentheses characters at the expense of potentially hiding function calls where anything can happen. I'm not sure why D joined the club given it doesn't have a corresponding de facto GUI framework, and its users even discourage it.