Hacker News Reader

Comment by adevine | Hacker News Reader

I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients needing to change.

Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY. The inability to do this in Java fundamentally breaks encapsulation.

View on HN

> Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY.

Others have noted that in many contexts in C# there is a difference, so clients do need to know.

As far as Ruby, clients definitely need to know, its just that since public fields can't happen in Ruby, its always method-based access for the normal cases.

Both of these lines are always calling a method on "obj" in Ruby:

  foo = obj.a  # equivalent to foo = obj.a() 
  obj.a = foo  # equivalent to obj.a=(foo)

While these are using instance var (the closest thing to a "field" in Ruby) access:

  foo = obj.instance_variable_get :@a
  obj.instance_variable_set :@a, foo
  foo = obj.instance_eval { @a }
  obj.instance_exec { @a = foo }

There's no common syntax like C#-style properties that unifies field-based and method-based access, so Ruby is sort of the extreme opposite of attempts to have "properties" that make method-based access look the same as field-based access in the same language, even though its method syntax can make method-based access in Ruby look like field-based access in a completely different language.

> Others have noted that in many contexts in C# there is a difference, so clients do need to know.

Which is why C# added automatic properties. You get the expandability without breaking clients or having to read/write extra code.

    public int Foo { get; set; }

Which becomes even more useful over a field when you can do:

    public int Foo { get; private set; }

Last time I checked (long ago), properties in C# don't work as ref or out parameters. Since C# actually distinguishes between ref and out parameters, it would be pretty easy to extend the language such that properties work whenever fields work, but sadly no one but me seems to care.

See the following example for why that is excluded.

    public string Foo { get { return ""; } }

    private void DoBar(ref string input) { input = "123"; }

    public void Main() { DoBar(ref Foo); }

Typically C# points you towards using a different methodology than ref/out parameters. But I do agree it is annoying when you want to use them.

Python has a solution to this. There are decorators that allow you to access methods as if they are properties:

    class Foo(object):
        def __init__(self, bar):
            self._bar = bar

        @property
        def bar(self):
            return self._bar

        @bar.setter
        def bar(self, value):
            self._bar = value

As does Objective-C, and JavaScript.

You haven't addressed his comment at all. Either you're building an immutable object and fields are the proper choice, or you're building an abstract, stateful, concept in which you should be using methods that may or may not map to fields.

Reply on news.ycombinator.com