Hacker News new | comments | show | ask | jobs | submit login

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.



It is addressed by better design.

First off, it's important to know the difference between value types and objects.

For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that.

Objects encapsulate mutable state, and getFoo() and setFoo() are inappropriate methods to have. They should be things that affect the behavior of the object, not simple setters and getters.

The big issue is that a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming. But we know now (well - some of us), and there is nothing in Java that prevents you from doing it well.


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.


> 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.


That works alright up until you need to integrate with third party libraries like JSF, Seam, Hibernate, Jaxb, Spring, EL, plenty of other stuff that requires a "javabean"

Sure, you can beat the big ones into working, and there is generally no shortage of libraries in Java. But at some point you are just wasting resource to work around other people code. Java has properties and some libraries use them.

Discussing if you should use them at all is offtopic, the real problem is that java has properties but instead of being a language/compiler supported feature, it is only defined as a "convention" with some half-assed support classes. Seeing how popular properties are, that either needs fixing or deprecation (starting with all the Oracle provided framework that use them)


> It is addressed by better design.

This! A lot of the horrible Java you see around is nothing but an artifact of mindlessly applying patterns to constructs that don't need them.

> a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming.

Which is quite unforgivable, considering Smalltalk has been around since the early 80's.


My problem is I don't think there's any agreement what Object Oriented Programming is and isn't, so it's pretty hard to "properly do it".

Let's see. OOP generally involves "objects", ie structs or records with visibility controls on fields, sporting "methods," ie functions with a magic/hidden this/self argument. This alone doesn't buy you much, and in fact is quite inflexible when compared to good old ADTs, so let's hope there's more to it.

OOP does not mean "all methods are defined within the class declaration/file" a la Java, plenty of OOPLs allow external method definition. So it doesn't mean "well in OOP I always know the behavior of my class" when you have friend functions etc.

OOP might mean "abstract classes" ie virtual methods. This leads us to inheritance, which is a) not confined to OOP and b) widely criticized. Remember that inheritance != polymorphism, c.f. Visual Basic for instance (at least VB5. Showing my age...). In practice, OOP usually invokes a great-chain-of-being-like hierarchy descending from Object, but again this is not universal.

OOP generally means "polymorphism", but the mechanisms vary widely. OOP's "Classic" inheritance-driven polymorphism is probably the worst way to do it, good for quick code-reuse and that's about it. "Interfaces"/pure virtual classes are a design pattern on top of abstract classes, better expressed as mixins or type-classes.

OOP generally implies strong typing but not always (python). OOP typing is quite clunky, especially in "noun-oriented" Java. You can make an argument that the rise of DI frameworks is in response to having impoverished type systems.

My semi-rant here is because people say things like "do it this way, it's good OOP" without there being any agreement about whether we're discussing polymorphism, inheritance, encapsulation, factoring, normalization, or design patterns that are largely a response to the confusion.

On the other hand we have folks like the clojure crowd bagging on OOP using similarly vague concepts like "OOP means stateful objects/side effects" ...


> This alone doesn't buy you much, and in fact is quite inflexible when compared to good old ADTs, so let's hope there's more to it.

It at least buys you a way of organizing your code that makes it easier to understand not just for yourself, but other programmers who read it in the future. Creating objects and using data types isn't really mutually exclusive, you use both as needed.

> OOP does not mean "all methods are defined within the class declaration/file" a la Java, plenty of OOPLs allow external method definition. So it doesn't mean "well in OOP I always know the behavior of my class" when you have friend functions etc.

This is true. The main benefit of OOP in this regard is to help see the interactions between related groups of functions as organized into objects.

> OOP might mean "abstract classes" ie virtual methods. This leads us to inheritance, which is a) not confined to OOP and b) widely criticized. Remember that inheritance != polymorphism, c.f. Visual Basic for instance (at least VB5. Showing my age...). In practice, OOP usually invokes a great-chain-of-being-like hierarchy descending from Object, but again this is not universal.

Inheritance definitely has downsides and should be considered carefully when used, but it also has valid use cases. As with any language feature, it really is more of a question of is this useful to fix the problem I'm trying to solve? Granted, a lot of programmers (at least from the code I've worked on) seem to see inheritance as a universal hammer to their current problem nail :)

> OOP generally means "polymorphism", but the mechanisms vary widely. OOP's "Classic" inheritance-driven polymorphism is probably the worst way to do it, good for quick code-reuse and that's about it. "Interfaces"/pure virtual classes are a design pattern on top of abstract classes, better expressed as mixins or type-classes.

Whether mixins, type-classes, or a polymorphic inheritance is the right choice really depends on language and problem space. At least with mixins there are definitely circumstances where a mixin could have so many methods that it is essentially a form of multiple inheritance. Again, knowing the right tool for the job and knowing what limitations your development language has is more important than the existence of any one feature or tool.

> OOP generally implies strong typing but not always (python). OOP typing is quite clunky, especially in "noun-oriented" Java. You can make an argument that the rise of DI frameworks is in response to having impoverished type systems.

I'm not sure about DI being the result of impoverished type systems. Generally DI is about insuring that function dependencies are explicitly consumed rather than implicitly existing somewhere as a more global state. DI is more about contract enforcement on functions than anything else.

> My semi-rant here is because people say things like "do it this way, it's good OOP" without there being any agreement about whether we're discussing polymorphism, inheritance, encapsulation, factoring, normalization, or design patterns that are largely a response to the confusion.

This is definitely the crux of it. "Good OOP" is a meaningless phrase for the most part. What exactly is good for a project? Given the amount of tools available in OO languages, many different approaches could be used that would function as good based on your particular problem and developers.


This reminds me of two tweets from Nat Pryce[1][2]:

> Colleagues & I once doubled system's functionality & replaced 750K lines of Java with 50K lines of ... Can you guess the language.

> Of course it was Java!

[1] https://twitter.com/natpryce/status/409034320108867584

[2] https://twitter.com/natpryce/status/409232836945010688


I agree with your design idea, but it fundamentally misses the point of getter auto-properties and that is binary compatibility in the case of future change. That is, if you need to add some functionality to the accessing of the variable. Now I personally don't think this happens much, but it would be nice if the language allowed something that preserved binary compatibility across that change and was not verbose.


I agree and I hate getters, but I am one of those who still hasn't figure out how to do OOP correctly. Do you have an example or maybe some suggested reading? For example, if I have a user object, with name, age, number, how would that work without get/set? I'd love to avoid it, I hate the bloat it creates, and also how frivolous it seems to test get/set.


Here's a tip: instead of changing your objects, you can create a new object with the same values except the ones you want to change.

Another option is to use builders (that are mutable), to build/copy your immutable business (?) objects.


That's what we do at work. Then when work is done, I look at OCaml and repeat the mantra "I'm not going to think about how many lines it takes in Java to do a functional update 'let foo2 = { foo1 with foo_field = "bar" }'".

It is possible to have immutable objects in Java and have the equivalent of functional updates, but it's a hell of a lot of pointless boilerplate. It still beats traditional Java beans, though.


Well, the answer depends on the function, the purpose. I suppose he's saying that you should encapsulate with the object. For example, you have an OrderLine object, you don't `o.setStatus(CANCELLED)`, you `o.cancel()` etc.


That examples makes sense, but what about Strings and other types? I'm not sure you can do the same thing for a User object with name, age etc. I'd love to not have getters/setters but I have yet to see a replacement for all get/set scenarios.


That's a Plain Old Data object and back in the day the Sun Java Coding Conventions recommended public instance variables for classes which "would have been a struct if Java supported it" or something like that.

I suppose it's all about behaviour. If the class is literally just a struct - a box for data, there's no functionality to describe. Choosing public instance variables vs. getter/setter is just a matter of choice at that point.

The latter let you check Preconditions, etc. but that means that you actually have some invariant you intend to preserve (date of birth of the user cannot be in the future, for instance, so your well-formed user has some characteristics). Any members that can take any value their type permits should, in my opinion, just be public. Logically if you perceive that you could have some invariant in the near future, you'd want to have getters/setters but there's no point overdoing it.


The parent would have the `User` type as a value type, with read-only final fields.


Anyone know what the "sjavac" is about? The link just talks about improving it so it can become the new default... but what is better about it? Is it just the new javac?(why not just in-place upgrade javac then?)

(link provides no real details: http://openjdk.java.net/jeps/199)


I was curious myself. I dug up the original proposal to create sjavac, which is here: http://openjdk.java.net/jeps/139


Interesting -- finally bringing multiple-core/process compiling to javac. Although, I must admit, I have yet to work on a project where compile times were a major issue. I guess I'm just in the habit of typing "ant release" and getting some coffee ;)


It's unclear if you are poking fun, but one of the major features of Eclipse (and ejc, by extension) is the "compile on save", so there is no compilation step while working in your IDE (unless, of course, you desired one).

If that is a goal of the sjavac project, then the ability to compile in parallel the different branches of the dependency tree for a set of classes would make for a major upgrade in user experience.


This only works well if we get named parameters, too (and maybe defaults). It is too easy to make mistakes with lots of subsequent constructor arguments of the same type.


We already have that, it's called the Builder pattern.


Up until recently, I've enjoyed the builder pattern. It becomes a pain in the ass though when your objects are deeply nested.

For example, with protocol buffers you end up doing things like.

AlbumCollection collection = user.getPreferences().getFavorites().getAlbums().toBuilder().addAlbum(album).build();

Favorites favorites = user.getPrefernces().getFavorties().toBuilder().setAlbumCollection(collection).build();

Preferences preferences = user.getPreferences().toBuilder().setFavorites(favorites).build();

and then you have to work your way up the chain of builders. Such a pain in the ass for something that could be much simpler with getters and setters.


This seems like a perfect example of a pattern applied in the wrong way. The builder pattern is supposed to be used to construct new instances (in other languages named parameters make it pretty redundant). I could perhaps understand allowing people to batch up changes but when you're forced to switch to a builder and back again to make a change to one field you've definitely got a poor design. The example seems particularly egregious because you're also forced to walk the domain where really you should just be able to do:

    user.addFavourite(album);


His example is creating new instances. It just happens to be creating them from existing instances. Basically a clone and change kind of operation.

You are right that normally you'd want the addFavourite method but in his example he is dealing with generated code which has a tendency towards verbosity.

You could add the method if Java allowed extension methods...


If you used the generated builder methods provided by protobufs, would it really be that bad?

  user.getPreferencesBuilder()
      .getFavoritesBuilder()
      .getAlbumsBuilder().addAlbum(album).build()


> Up until recently, I've enjoyed the builder pattern. It becomes a pain in the ass though when your objects are deeply nested.

That and good luck adding a new required field in your "constructor", because you just gave up on statically checking the parameters of the "constructor".


Can't say I understand the downvotes on this one. If you add a parameter in a traditional constructor but don't update the site calls, your code won't compile. If you add a builder method, your code will still happily compile, you'll have to wait until runtime to get an exception, if you added a check in the build() method. That's something to think about, just like you give up safety for convenience when you move to a DI framework.


So for every class in Java, we just create a corresponding builder class, because we lack certain features in the language?

This is not a solution, this is a workaround.


> The big issue is that a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming.

Bollocks, there were already plenty of OO languages when Java appeared on the block.


Sure, but more radicial OO languages like Smalltalk were full of getters/setters too (e.g. in Smalltalk all member variables are private, so getters/setters are the only way to access those) so it makes sense to think that this was just the way to go.


Eiffel introduced properties in 1985.

The famous CLOS book was written in 1988, which makes use of slots instead.

I am at work now, otherwise I could provide more information.


Then don't use getters and setters... A lot of complaints people have about Java seem to be about the way in which they choose to write Java.

My somewhat unorthodox rules for writing Java:

1. Don't use private. No reason to restrict yourself or others, and do extra typing. Friendly is a perfectly good default.

2. Don't use reflection. Reflection is only useful for making frameworks. Frameworks don't reduce the complexity of the problem you're trying to solve. Don't use them.

3. Don't use getters/setters. Sometimes they make sense for updating a cached value, or using a different underlying representation, but in general it's unnecessary clutter. If you still want them (e.g., for code style reasons), just generate them.

4. Don't use other people's code (tongue-in-cheek). If you use third-party libraries, consider wrapping them in your own interfaces as needed. This makes it easy to change the implementation and perform tests. It's not much effort, since you'll rarely use more than a limited subset of the functionality offered by the library. If you need a large subset, then just use the library directly.

5. Use final. Immutability makes programs simpler, more efficient, and inherently thread-safe.

6. Consider writing bean classes as follows. It's simple, efficient, thread-safe, and has a clean syntax (item.name):

    public class Item {
        public final int id;
        public final String name;

        public Item(int id, String name) {
            this.id = id;
            this.name = name;
        }
    }
7. Use an IDE, refactor, find references, generate code. It's easy to changes names and styles later, so just focus on important things like performance and reliabiltiy.

8. Keep improving the way you write your code, don't listen to the crowd.


Nothing pollutes java source more than code which REQUIRES setter methods for functionality. If you have classes which require constant mutable access to internal state, your design is probably flawed.


>If you have classes which require constant mutable access to internal state, your design is probably flawed.

How do you account for value objects in that statement? Are you saying there should be no such thing?


There's no reason value objects need to be mutable. In fact, they shouldn't be mutable. They're just data. Why would you need to mutate them?


Well, in the strictest since, I suppose a "value object" is technically one that is immutable by definition. So, to your point, I should clarify that here I'm instead speaking more loosely of an object that is chiefly comprised of data elements vs. behaviors.

So, a common use case might be loading data from a DB, changing several fields, then writing updates back to the DB.


Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?


IMO Dart has the best implementation of properties, which you can start out as normal fields, e.g:

    class Rectangle {
      num left, top, width, height, right bottom;
    }
and can access like normal:

    var height = rect.bottom - rect.top;
But can later be changed into a computed property without affecting the above callsites, e.g:

    class Rectangle {
      num left, top, width, height;

      num get right             => left + width;
          set right(num value)  => left = value - width;
      num get bottom            => top + height;
          set bottom(num value) => top = value - height;
    }
C# is a close 2nd, but it's not binary (or reflection) compatible to change from a field to a property for call-sites (i.e. it's only source-compatible).


Your comment about changing a field to a property being a breaking change in C# is correct, but in practice, C# programmers tend to use auto properties (e.g. public int Left { get; private set; }) rather than public fields. These are fully fledged properties, but the getters and setters are implemented by the compiler (and back directly onto a compiler-generated field). Because they are properties, they can then be changed to computed properties (or e.g. validation added to setters) without breaking binary or reflection compatibility.


Why does it matter if it's binary compatible? How does that affect the programmer? I guess I don't understand the difference/significance between binary and source compatibility?

I'm surprised to hear that it's not reflection compatible. As a Java programmer, I assumed that was the main point of C# properties: Create a property now because there's no logic needed, but if you need logic in the future you can change the code and nobody outside needs to be aware of the change.


Binary compatibility is important when accessing properties of a type defined in another Assembly, i.e. if an Assembly was updated where a Field was changed to a Property it would break access from dependent Assemblies.

In .NET Reflection, Fields and Properties have distinct API's, i.e. fields can be accessed with `type.GetFields()` and properties with `type.GetProperties()`. The API's are basically wrappers around how they work, i.e. Fields let you get/set an instance's field value whereas with Properties you're instead invoking the properties getter/setter method accessors.


> As a Java programmer, I assumed that was the main point of C# properties: Create a property now because there's no logic needed, but if you need logic in the future you can change the code and nobody outside needs to be aware of the change.

That's the point, but its not directed at reflection, and reflection goes around behind the scenes of the superficial access-notation compatibility. Which does make properties a badly leaky abstraction, which is problematic since their main reason for existing is to plug a leak in the abstraction provided by the method/field distinction.


Another important aspect of properties in C# is that they are a target for metadata (i.e. Attributes). This is something that's frustratingly broken with the method getter/setter approach. And while you can fix it by convention (e.g. a priority list for lookup on the getter, then setter, if those exist), it ends up being inconsistent and unnecessarily painful.

Consistency of access in Java is also really problematic for the same reason. Which pair of getter/setter methods represents a reified property? This is often done by naming convention, that's usually, but not always consistent (getFoo/setFoo is common, but there's also isFoo/setFoo, isFoo/setIsFoo, foo()/foo(value), etc.). Worse (and this is something both Android's flavor of Java SDK and Objective-C have fallen prey to), not all properties are written symmetrically (e.g. getText() and the various setText() methods on an EditText in Android, although there are some where all of the setters are subclasses of the only getter -- even worse).


Ruby is quite similar.

attr_accessor :left, :top, :width, :height, :right, :bottom

And you can change these to computed properties (regular methods) later without affecting the callsites


In C#, these aren't 100% source-compatible either. For example, you can't pass properties using ref or out parameters.


Amusingly, your Dart solution is exactly what Groovy does, which is where this whole thread started.


afaik scalas properties are as good as in case of dart. Also, operations like + are also normal methods on numbers.


The purpose of a getter or setter is to abstract the implementation out from the usage. Computed properties (e.g. C#'s ability to replace a concrete property with a virtual property without breaking any code) do this without requiring mindless implementation (boilerplate code) for the common case (a property that is exactly what it seems to be).

As an added bonus, you don't need to write foo.getBar(), you can just write foo.bar and it Just Works, whether foo.bar is a concrete implementation or a computed property.

Look at this blog post for example:

http://java.dzone.com/articles/java-properties-without

The sad thing is the request here is for something more ugly than what is really wanted (this is just automatic getter/setter implementation -- computed properties are better both for developers and consumers of their output.


The problem is that you cant add computed accessor methods to java without breaking code backwards compatibility. This is because a public fields and a public methods have different inheritance semantics - public field access does not trigger polymorphic resolution. Hence auto replacing it with a access method would break any code that relies on the static resolution of the public field (i.e. resolution by referencing type). To fair there probably isnt much code out there that would fall foul of this since there isnt any good reason to write code that relies on public field "hiding" by subclasses, but it would be technically non backwards compatible.


In python the default is that things that look like attributes/properties REALLY are direct access. If you later need to shim them out into a function you use the @property decorator (and foo.setter if you need read/write)

    class Blah(object):
      foo = 2 # A normal property. Direct access

      @property
      def bar(self):
        return self.some_lookup_method()
    
      @bar.setter
      def bar(self, value):
        self.set_the_bar(value)


Thanks for mentioning this. I've found the Python approach works really well in practice.


What's wrong with getters and setters?

It's just redundant code. Most of the time developers don't actually need to override the basic get/set operation on a variable. Yet you have to write the get/set methods over and over.

How do other languages address this issue?

Scala does a good job. You don't need to actually write a get/set method. But if you wanted to modify getFoo() you would simply implement the method with your custom getter


The problem with getters and setters is that the code for them is nearly identical, yet they have to be written in nearly every single class:

  // Sorry if there are any mistakes, I have not
  // written any Java code for quite some time.
  public class Point
  {
    private int x;
    private int y;
    .
    .
    public int getX()
    {
      return x;
    }

    public int getY()
    {
      return y;
    }

    public void setX(int newX)
    {
      x = newX;
    }

    public void setY(int newY)
    {
      y = newY;
    }
  }
Look at how long the class definition is for something so basic!

In Common Lisp there are two ways to define classes/structures, defstruct and defclass. Defstruct[0] automatically automatically defines everything for you:

  (defstruct point  x y)
will define the procedures make-point, point-x, point-y, (setf point-x), and (setf point-y). The cool thing is that they are all procedures. It easily change the class definition without changing the code that uses it. There are also some additional options for defstruct to specify default values, how to print the structure, as well as what prefix to use (the default is the name of the structure, 'point' in this case).

Defclass[1], while much more verbose than defstruct, is much more powerful:

  (defclass point ()
    (x :writer set-x :initarg :x)
    (y :reader get-y :initarg :y)
    (z :accessor z))
will define procedures, set-x, get-y, z, and (setf z). Set-x and (setf z) are the setters, while get-x and z are the getters. To construct a point that is defined this way, one has to use the procedure make-instance which will take keyword parameters[2] :x and :y, for x and y respectively.

  [0] http://www.lispworks.com/documentation/lw445/CLHS/Body/m_defstr.htm
  [1] http://clhs.lisp.se/Body/m_defcla.htm
  [2] http://www.gigamonkeys.com/book/functions.html


For c# just:

public int Age{get;set;}

no need to declare private variable, get or set methods.


And you can replace it with a virtual property in the future (changing the underlying implementation) without breaking anything. And user code ends up simpler and more readable too:

foo.baz += foo.bar;

vs.

foo.setBaz( foo.getBaz() + foo.getBar() );


That example reminds me of this recent post on The Old New Thing: http://blogs.msdn.com/b/oldnewthing/archive/2014/08/14/10549...

Interesting behavior.


Of course, setters don't protect you from this either.


C# introduces the concepts of fields and properties. I dont remember which is which but I think properties are in fact getters and setters,without the verbose "object.getProperty()" syntax , you just write "object.property" and it's call a getter function or a setter function.

Basically you keep states encapsulated without have to manually write methods,you just write methods when you need then.

Java verbosity on that matter is totally unecessary.

Granted when one use an IDE refactoring features can help,but still... A great strenght of the Java language is its stability.But stability doesnt mean a language needs to be that verbose.


> C# introduces the concepts of fields and properties.

This goes back to at least Eiffel (1985).


To add another example to the list, Ruby lets you list which attributes can be read/written and which ones can only be read on top. Something like.

  class Car
      attr_reader :model, :company # only read
      attr_accessor :color # read and write
  end


It's worth noting that in Ruby the difference between attr_reader and attr_writer is not the same as read only and write only. You can write to something set with attr_reader. All attr_writer does is allow complete reassignment of that particular instance variable.

This is pretty trivial so bear with me... If you have something that looks like this...

    class Person
      attr_reader :children

      def initialize
        @children = []
      end
    end
You can then do this...

    x = Person.new
    x << "Bobby"
You will have then altered the value of @children without completely reassigning it.


Kotlin is pretty nice for that. Also, project lombok is nice for Java code generation. I wish it became more "standard"


+1

It is pretty astonishing they haven't done something about that. It doesn't seem like it should be a very hard language feature.


This doesn't solve the problem entirely or address your valid complaint, but it does do a good job of hiding it for now: http://projectlombok.org/features/GetterSetter.html


Amen. How about some language keywords like "readable" and "writeable"?

public class Foo { public readable int canSeeeMeButCantChange; public writeable int cantReadMe; public int existingBehavior; }

These are pretty simple changes to the compiler and verifier. You would make canSeeeMeButCantChange an invalid "left hand" variable in the compiler, and the verifier would have to check for any writes to the fields. cantReadMe would be an invalid right hand variable, and a similar check for the verifier. Any other public field behaves as normal.


The other "Missing feature" is null safe ".". Other languages have it, but I don't know what the technical name is... basically:

Integer val = some.other.chain.of.objects.value;

In Java, this code has a huge potential for NullPointerExceptions. Instead a new operator (yes, I know) like:

Integer val = some.?other.?chain.?of.?objects.?value;

If any of the intermediate objects are null, the whole assignment becomes null. This could be done with a smarter compiler (easy way), or a new JVM bytecode (probably 'better' but not easy).


This is solved in a more general way in Java 8 via monadic optionals. The basic idea is to wrap your nullable objects in an Optional<T>, which then both forces you to deal with the possibility of the value being absent and gives you good tools for doing so. Your example, with Optional, looks like this:

T obj = ...;

Optional.of(obj).map(T::some).map(U::other).map(V::methods).getOrElse(null);

Not quite as clean syntactically, but much more general, as the same operations can be applied to other monadic objects.


The sugar your parent proposed would still be nice and has precedent in other languages with option types. Swift has something very similar[0], and Rust is debating it[1]. Haskell's do-notation and Scala's for-comprehension are other solutions to the same general problem of conveniently using option types.

It may be a good thing to only support that sort of convenience for option types and not for nulls, in order to further encourage their use. Although using nullable types is already pretty darn convenient!

[0]: https://developer.apple.com/library/prerelease/ios/documenta... [1]: https://github.com/rust-lang/rfcs/pull/204


This is kind of a pedantic distinction, but the behavior you've described is actually Functor behavior; I think Monads allow for Functor-like behavior as part of their definition (not sure, I'm neither a category theorist nor an experienced Haskeller), but their use is something a little bit different. Monads allow you to do two things:

1) Lift regular values into monadic ones in a generic way. Let's say that we have two Monads - Optional and List. There should be a way such that we can take a non-monadic value (the part that will go inside) and turn it into a Monad. So, assuming Monad is a Java-like abstract class, the following should be possible:

    Monad<String> m1 = Optional.lift("hello");
    Monad<String> m2 = List.lift("hello");
2) Flat-map, typically called bind in this context. Given a monad and a function that takes a value and returns a monad, we should have some way of combining the resulting monads if we were to map this function over the first monad's internal value. So for instance, given an optional string, and a function that takes a string and returns an optional int, we should have some way of combining the Optional<Optional<Integer>> into just an Optional<Integer>. So, in the following contrived example...

  // Returns a UTF8 string value from a database, may fail
  public Optional<String> getUtf8Name() { ... }

  // Returns the length of a String if it contains exclusively ascii characters
  public Optional<Integer> getAsciiLength(String str) { ... }
... you can compare the differences between it and the Functor's map:

  Optional<Integer> asciiLength = getUtf8Name().bind(getAsciiLength);
  Optional<Integer> otherAsciiLength = getUtf8Name().map(getAsciiLength).getOrElse(Optional.absent());
As it turns out, you can implement the Functor's map method in a generic way using lift and bind.

  public abstract class Monad<A> implements Functor<A> {

    /**
     * Implements Functor's map method.
     */
    @Override
    public <B> Monad<B> map(Function<A, B> fn) {
      return this.bind( innerValue -> this.lift(fn.apply(innerValue)) );
    }

  }


    Monad<String> m1 = Optional.lift("hello");
    Monad<String> m2 = List.lift("hello");

Shouldn't that be

    Option<String> m1 = Optional.lift("hello");
    List<String> m2 = List.lift("hello"); 
?


This is called null-value propagation. It's coming to C# (6) this year.


Groovy does this, although frustratingly not with array accesses last I checked.


I requested array accesses on the Groovy mailing list 7 years ago, see http://groovy.329449.n5.nabble.com/Indexed-properties-td3396...

I never did fill out a GEP but you could try your luck by subbing one, see http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancemen...


Is that not what final does?

I'd be interested in seeing C#-like getters and setters. As long as they're just getting and setting, they're implied, but if you want to introduce a check or some other logic, you can do so without changing the signature of the class.

Groovy does some of this, but it requires you to use the name of the field - ie. person.age will check for a getAge() method first, then fall back on the "age" field. I quite like that methods have verb-names, but I don't want to verb my fields.


Yes, sort of like final... but different.

I was thinking this is more for _public_ variables... so like internally, a class could modify it's own readable fields, but code external could read only.


I do like how C# handled this, FWIW.

  public int MyProperty{
    get; //public
    private set; //private-only setter
  }
but obviously there are a lot of ways to skin that cat.


Methods that actually do something should be verbs, but if it's just reading a property it should look like it's just reading a property. And having all the methods on a class start with get* is a pain for autocompletion.


Hmm. I guess you're right. I dislike Groovy in other areas so it's not a path I've gone deep down.

Especially for private APIs i Java I have actually tended to default to public final members, without verbs.


> Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address.

We ran out of patience and switched to Scala. Never been happier :)


Groovy replaces package-scoped variables with private vars and autogen'd getter/setters. So much nicer.


I admire Java for the fact that it is significantly more painful to write mutable rather than immutable classes.

I love C#, but I do wish that setters weren't so easy to define (and that classes were sealed by default, and that fields were read-only, and that all extant warnings would become errors, etc.).


I agree 100%, but the problem is the culture that has grown up around Java. The whole Bean concept encourages violation of encapsulation. IDEs provide automatic generation of accessors and mutators. Many Java programmers have been trained to expect them. At this point, encouraging good OO practice is shouting against the tide.

That being said, I still make my classes immutable unless there is a damn good reason not to.


In Java culture immutable generally means private final member with only a getter and no setter. I would argue that this is good OO design as the purpose of OO design is to protect your interface from future design changes. If you need to change your accessor, you already have one. If the member needs to be mutable at a later date you need only remove the final keyword and potentially add a setter. The interface remains backwards compatible.


I disagree. If you require an accessor to actual internal state, you should rethink your dependencies and reassign some behaviors. Accessors should be rare, mutators almost non-existent.


And making your instance variables public doesn't solve that for you?


States(properties) should never be public or it breaks encapsulation.That's why a language that allows a property to be a method under the hood is usefull, because the state is still encapsulated.

State changes can have desirable side effects.If you expose an instance variable directly it's harder to encapsulate that.

Of course there are exceptions. If you have a class that is meant to be only a parameter bag(in an rest API for instance),that's ok,imho.


I work just fine in a language that has no "private" variables or methods. It's not for everyone, and it requires some discipline to not get burned.

Don't get me wrong, I'm big on encapsulation and separation of concerns, etc. But you don't need to force "privacy" onto your class's users in order to achieve it.

The worst thing about having everything public (this is python, btw) is that sometimes it pollutes the auto-complete, and hinders discoverability. It's also not immediately obvious what the user should/shouldn't have access in your class.


[deleted]


Here's a class C with a variable v of type T. It's supposed to be something that the rest of the world can access. You can make it public. Or you can make it private, and write

public T get_v() { return v; }

So far, not much difference. Both let the world access the variable, and both break encapsulation by doing so.

The difference comes when the class gets more complicated, and v changes. Now v might be null, whereas it never could be null before. But if it is, then what the rest of the world saw as v should now be some default value. So we can say:

public T get_v() { if (v != null) return v; else return default_T; }

and life goes on for everybody that was using v. But if all we had was a variable that everybody accesses, then all the users have to change. They either have to access the new getter or, worse, they each have to copy the logic to check for null.

This is how the getter encapsulates the inner workings of the class, and why it's a really good thing.

P.S.: How do I specify code formatting on HN?


Indent the code with two or more spaces:

  public T get_v() {
      return v;
  }
See: https://news.ycombinator.com/formatdoc


"P.S.: How do I specify code formatting on HN?" I'm not sure if there is one. But if you want, just make a pasteIt, or a fiddle. Not sure which one is the one that caters for C/C++ code.


Your public facing methods/accessors are a sort of contract between a class, and whatever uses it.

The contract basically says: "I will behave as you expect me to and as we agreed but only as long as you only interact with me in the predetermined(designed) ways that I allow you to"


If you want a quick and dirty method that won't bite you in the ass, you can declare the variable public final. If you can live with all that entails.


Not exactly comparable (because everything is immutable), but Haskell has sort of a cool approach to setting and getting fields.

Let's say you have

    data Point = Point {x :: Int, y :: Int}
If you have a Point object called "point", you can get x by doing

    x_coord = x point
If you want to create a new Point with x set to 5, you can do

    point' = point {x = 5}


F# has a similar concept via the with statement. To use your example:

    type point = { x: int; y:int}
    let z = {x = 5; y = 10} 
    let y = {z with x = 17}


Interesting, Scala equivalent is:

    case class Point(x: Int, y: Int)
    val p1 = Point(5,10)
    val p2 = p1.copy(x=17)
How does F# handle nested data types? In Scala if you want to copy a case class of a case class (of a case class ...) it can get boilerplate-y as you have to copy outside-in through each property a la:

    x.copy(acase.copy(bcase.copy(cprop=1)))


It isn't perfect, but Lombok[1] helps with this. It uses annotations to automatically generate getters and setters. The downside, of course, it yet another dependency and more annotations.

[1]: http://projectlombok.org/features/GetterSetter.html


You can setup your build process to "delombok" your sources, so that the dependency would only be compile-time (which is pretty neat). Also, Lombok has @Data http://projectlombok.org/features/Data.html


What's even better is @Value with @Builder :) Immutability is the best.

http://projectlombok.org/features/Value.html http://projectlombok.org/features/experimental/Builder.html


I'd use immutable value classes with AutoValue: https://github.com/google/auto/tree/master/value . It's developed by the googlers behind the awesome Guava library.


You can always do something like this http://benjiweber.co.uk/blog/2014/03/20/c-style-properties-i...

Although I prefer not using getters & setters at all.


that's not really because of the language, but mostly because of frameworks and patterns available for the language (Java Beans, reflection-oriented frameworks and so on). Often, getters and setters are more an habit than a need. A while ago I wrote against that: http://www.refactoringideas.com/getters-and-setters-gone-wro...


You can always add Project Lombok as a dependency and the issue is gone. I know it is a third-party library but there's nothing bad about that.


Why not just declaring the fields public and access them directly? Is there anything I am missing?


What if you only want a getter? The `final` keyword is too restrictive.

Also, it breaks encapsulation, because your internal storage should be changeable without ruining your external surface area.


If there's a getter and a setter for a class field, you can just make it public.


The problem is that in Java at least, you cannot.

At least if it will be ever used by code beyond your control.

Because then you'll never be able to add a getter or setter later without breaking people's code.

Java is frustrating in that regard. As it should be able to deal with automatically invoking getters and setters when needed (it already inlines getters and setters at runtime, this is "just" the reverse), but it's a language decision that it doesn't.

As an additional bonus, this would help reduce the (legendary) verbosity of Java. a.b += c.d is much easier to read than a.setB(a.getB() + c.getD()). And don't get me started on Java's generics or lack of operator overloading...


burn your getters




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: