Hacker News new | ask | show | jobs
by Theriac25 4629 days ago
Doesn't C# have "magic" getters and setters, where code like "foo.bar = quux;" might mean a function call? To me, that's not clearer at all.
3 comments

Yes. However, C# uses the convention that capitalized "fields" are actually properties, and lowercase ones are true fields.

For example, Foo.X might be an x position, returned from a getter method, and set with a setter method. Internally, the class make use the Foo.x field to store it, in which case the getter and setter are trivial. In fact, C# will write them for you The property could look like:

    int X{
        get;
        set;
    }
(Though my syntax might not be completely correct, I haven't used C# in a while). C# will automatically create a private field to store the value for x, and the getter and setter will work as expected.

Classes should, as a general rule, only expose properties and methods to the outside world. All fields should be private. Yes, accessing a property calls a method, but so does a Java getX().

Java uses the same rule, except getters and setters are implemented using setX(int) and getX(). C# properties are the equivalent. The client of a class should not care how the class stores values, but that the getters and setters work.

"However, C# uses the convention that capitalized "fields" are actually properties, and lowercase ones are true fields."

If only. In http://msdn.microsoft.com/en-us/library/vstudio/ms229043%28v..., Microsoft advocates:

"The PascalCasing convention, used for all identifiers except parameter names, capitalizes the first character of each word"

The UI in MonoDevelop / Visual Studio will show the differences during autocomplete. Also, fields should NEVER be public in a class.
I've written a lot of C# and Java (and others of course). It's really not an issue. If you're doing something expensive in a property getter or setter you're doing it wrong. If the function call doesn't get inlined and becomes a bottleneck in some tight loop you can just change it. Anecdotally, I have yet to see this occur in practice.

Also, as the guy below me pointed out, by convention you know that Foo is a property.

Exactly. It's (at least from what I've seen/read) common convention to make sure that getters/setters should be quick and have minimal side effects.

Your application shouldn't hang from a database call when you pull a property from an object. And obviously, methods doing such things should be documented appropriately.

Isn't not needing to know whether an object property is real or synthetic a feature?
Huh? Of course it is a feature. My point is that if something as innocent looking as property access can be an arbitrary method call, it may make understanding a piece of code more difficult. From the point of view of debugging existing code, which I've done a lot lately, hiding details that may matter in corner cases is not something that I want the language to encourage.
So you're against pretty much all encapsulation then?