4 ms·

Also lets you maintain your invariants. It's particularly useful for cache invalidation. Like if your object exposes a hash of all its public properties, you

by Pxtl 2y ago

Also lets you maintain your invariants. It's particularly useful for cache invalidation. Like if your object exposes a hash of all its public properties, you can invalidate the cached hash when a prop setter is called with a new value.

mrkeen 2y ago
You just reminded me of one of my main reasons to avoid getters, which the article didn't mention. Accessing a field will not invoke other code.
- Groxx 2y ago
  Unless it's synchronized. Then you could deadlock.
  - mrkeen 2y ago
    This got me curious, so I tried it out. I was unable to put a synchronized onto the field directly: error: modifier synchronized not allowed here public synchronized final Object field; But when I locked it in code: synchronized (field) { while(true) { .. I was still able to access the synchronized field directly without triggering a deadlock - whereas a getter() could be synchronized and trigger a deadlock. In any case, the article already made a strong points for immutability so you don't need to mess around with deadlocking crap.
    - jayd16 2y ago
      They're saying multiple things can synchronize on the same public field. Same reason you don't want to use this. Although I suppose they could mean the concept and not the keyword. A field might not be thread safe and there's no way for an object to guarantee thread safe access of to a field.
      - mrkeen 2y ago
        Deadlocking was raised as the objection to using public instead of getter. But in regard to deadlocking, using public is strictly better than a getter. You have to take a lock in order to deadlock in the public version. In the getter version, you can take a lock without realising it and then deadlock.
    - Groxx 2y ago
      nope, sorry, that's my mistake. I'm misremembering java, it has been too long :) thanks for the correction!
- Pxtl 2y ago
  To me that's just a matter of having standards that have clear requirements of what's okay to put in a getter - imho, refreshing invalidated caches (as long as they're lightweight and not like network communication) is perfectly appropriate. Anything with a side-effect that can be observed from outside of the object (creating the case where you get code just hitting setters and getters to cause side effects) is right out. I mean, Lazy<T> is a great example of use of getters.

by Pxtl 2y ago

mrkeen 2y ago

You just reminded me of one of my main reasons to avoid getters, which the article didn't mention. Accessing a field will not invoke other code.

Groxx 2y ago
Unless it's synchronized. Then you could deadlock.
- mrkeen 2y ago
  This got me curious, so I tried it out. I was unable to put a synchronized onto the field directly: error: modifier synchronized not allowed here public synchronized final Object field; But when I locked it in code: synchronized (field) { while(true) { .. I was still able to access the synchronized field directly without triggering a deadlock - whereas a getter() could be synchronized and trigger a deadlock. In any case, the article already made a strong points for immutability so you don't need to mess around with deadlocking crap.
  - jayd16 2y ago
    They're saying multiple things can synchronize on the same public field. Same reason you don't want to use this. Although I suppose they could mean the concept and not the keyword. A field might not be thread safe and there's no way for an object to guarantee thread safe access of to a field.
    - mrkeen 2y ago
      Deadlocking was raised as the objection to using public instead of getter. But in regard to deadlocking, using public is strictly better than a getter. You have to take a lock in order to deadlock in the public version. In the getter version, you can take a lock without realising it and then deadlock.
  - Groxx 2y ago
    nope, sorry, that's my mistake. I'm misremembering java, it has been too long :) thanks for the correction!
Pxtl 2y ago
To me that's just a matter of having standards that have clear requirements of what's okay to put in a getter - imho, refreshing invalidated caches (as long as they're lightweight and not like network communication) is perfectly appropriate. Anything with a side-effect that can be observed from outside of the object (creating the case where you get code just hitting setters and getters to cause side effects) is right out. I mean, Lazy<T> is a great example of use of getters.