4

Some methods are mutator methods, usually they return nothing, the so-called setters. Others, like the .plusDays() method of the LocalDate class, return a full, instantiated object of type Localdate, so if you want to change the object, you need to point your existing object variable to the newly created one.

Is there a way to know beforehand if a method will be a mutator, or work like the before-mentioned apart from looking at its return value?

ΦXocę 웃 Пepeúpa ツ
  • 43,054
  • 16
  • 58
  • 83
victor cortez
  • 51
  • 3
  • 1
    You cannot tell if a method mutates a state of an (or any) object, except you're looking into the source code. `LocalDate::plusDays` could also change an object combined with creating and returning a new instance. – Flown Sep 21 '17 at 06:18
  • 1
    The javadoc should state this, like in the method you mentioned : "Returns a copy of this LocalDate..." – Arnaud Sep 21 '17 at 06:18
  • if the class Foo has a method that returns a Foo, then it is a candidate for an inmutable class.... the doc may be helpful too – ΦXocę 웃 Пepeúpa ツ Sep 21 '17 at 06:19
  • To know for sure(-ish), you need to look at the documentation, but you can guess by the name (`set*`, `add*`, verbs are going to mutate; conjunctions and nouns won’t). – Ry- Sep 21 '17 at 06:19
  • By "beforehand", what do you mean? Before you decide to use it in your code? Or before invoking it at runtime (e.g. via reflection)? – dimo414 Sep 21 '17 at 06:22
  • 2
    "How can I do my best to avoid reading documentation like a sensible person?" – Kayaman Sep 21 '17 at 06:28
  • @Kayaman Developers should never be _forced_ to read documentation unless they're creating an implemention. It's why languages like Rust are attempting to enforce this at compile-time. No one likes being forced to read docs for clarity. – Dioxin Sep 21 '17 at 06:32
  • @VinceEmigh We have plenty of developers who don't read documentation already. I don't think that's something you want to strive for when you need to get things done instead of sticking to some heroic sounding ideals based on some nutjob's opinion. – Kayaman Sep 21 '17 at 06:37
  • @dimo414 sorry, in the specific context of this question, "beforehand" means "decide to use it in my code". – victor cortez Sep 21 '17 at 06:40
  • @Kayaman thanks for the shake of reality, the documentation is indeed a good resource, but the questions aims to clarify if there are any indicators code-wise, or maybe language-design-wise. – victor cortez Sep 21 '17 at 06:44
  • 1
    @Kayaman Have you read the JLS front-to-back? And the JVMS? You're a user of those, so you should have read the documentation, yeah? Or maybe you're like the majority who only reference it when something strange occurs and you need an official answer. Think of a fridge or a light switch: you use one, but how much have you read into it? Would you agree that users of a fridge, or a light switch, should not be obliged to read the documentation in order to feel safe using it properly? Yeah, it would be useful, but being *forced* to? – Dioxin Sep 21 '17 at 06:46
  • @VinceEmigh Well with modern day IDEs it's pretty hard to avoid reading the javadocs. If the JLS popped up like that, I'd read it a lot more too. I don't really understand why your hatred for documentation is so strong. Is it because it's usually non-existant or in the worst case it's wrong? So you want to go find the person who wrote the code and the documentation and strangle them both? If yes, I completely understand. – Kayaman Sep 21 '17 at 06:59
  • @Kayaman Its not hatred for documentation, probably wouldn't have lasted this long if I despised it. It's the mindset that we should be dependent on documentation. A sturdy interface could prevent the need to read documentation. Documentation is inevitable in many situations, but we should be progressing away from that (like common real-world objects) rather than enforcing it. See it as the philosophy of a nutjob, but aren't you glad we arent forced to read the JLS and JVMS to write Java programs? Docs for new, potentially obscure features make sense. Mutability isn't one, IMO. Just an opinion – Dioxin Sep 21 '17 at 07:22

2 Answers2

5

No, there is no way to know (short of looking at the documentation or implementation) whether a method will change some sort of state.

Methods that return void are generally going to change some sort of state (otherwise what are they doing?), but there's still no guarantee what will change (options include the object, one of its fields, the method's parameters, global state, or even the JVM runtime itself).

There's no general-purpose way to tell whether methods that return something will also have other side-effects or not.

If a type is immutable you can be confident that none of its methods will mutate its own state, but then the question has simply shifted to "how do you tell whether a type is immutable or not?" This is easier to answer, but still tricky. Static analysis tools like ErrorProne's @Immutable check are helpful but still fallible.

dimo414
  • 42,340
  • 17
  • 131
  • 218
1

Well, pure setters which follow the pattern void setProperty(PropertyType property) are likely to modify the internal state (ok, one could implement it in a different way, e.g. modify the state of the passed parameter, but that would be strange).

Methods found in Builders for instance (like Builder withProperty(PropertyType property)) are free to choose whether they update the state of the actual instance or create and return new instance holding the updated property.

In the end one cannot foresee whether one or the other implementation strategy has been chosen just by looking at the method, so one has to read the docs (and sometimes the code).

Florian Fray
  • 254
  • 1
  • 6