If I find the genius who thought using getters and setters everywhere was a good idea, i'll gladly throw him into an active volcano.

Hi, c++ and python dev here, what's a getter and setter?

@atheist when you like to use get() and set() because public in your mind is a category on PH

@atheist ok, jokes aside, when you use get() and set() with no complex logic on a private variabile when you could simply make it public

@atheist its the java/c# equivalent of an @property.

Once saw a function to the manual creation of setters. It was called..... getSetters()

Sadly it wasn't using Go. That would have been more amusing.

@8lall0 it is only about future requirements when you might want to do MORE than assigning or returning the value

@asgs that's exactly what everyone said ten years ago when they wrote those get/setters

Lol, qt requires you to create a getter, setter, and notifier when creating a property to be used in QML. QML uses these to interact with the property and notify binds of changes. Useful, but it does require a bit of boilerplate. Thankfully the boilerplate can be generated.

@8lall0 and then they moved to Lombok

It is good if we don't see those methods in our SCM no matter it gets preprocessed or not

@stop a property should be a computed attribute. Not a getter/setter.

@8lall0 jokes aside, my point was I've never used get/set. They're pointless. Either private, public const or public mutable. If they've got processing logic they're not really a getter/setter.

Python is the wild west of "hope your user does the right thing", but whatever.

@atheist python properties have the ability to be getter and setter.
@highlight
class X:
__value = 1
@property
def value(self):
return self.__value
@value.setter
def valueset(self, value: int):
if not isinstance(value, int):
raise TypeError("Value must be an integer")
self.__value = value

@stop that's called an "I'm gonna reject that during code review"

Also python duck typing, probably shouldn't be checking it's an int.

@stop I'm also vaguely against having the instance variable fall back to the class variable, as the class variable is mutable. But, as I said, python's the wild west of "hope"

@atheist

Why?

I thought the ability to transform a property into a setter/getter was intended. Everything I have read about this ability was always touted as a desirable feature.

Where does this fail?

I suppose my point is getter/setter is a code smell. If you're defining an api, I question whether the getter/setter methods make sense. It's gonna make SOLID harder because of inversion, and you're coupling your api to data, not functionality. Getter/setter methods don't have much benefit beyond inheritance and hiding implementation, but if you're trying to hide that kinda implementation, make data const, pass it to the constructor, forget about get/set. Otherwise I'd argue get/set shouldn't be part of your inherited api, it fails SOLID on several counts.

@Demolishun having a property or a getter that is a convenience method that computes something based on the state, is valid.

In c++ there are language level features that enforce correct usage of most setter type functionality, and python is python, you're better off documenting what is good instead of trying to validate it, because the user can do whatever the hell they want. Duck typing says "accept whatever and try to use it, if it doesn't work then complain". So validating that a value is an int, in python is wrong (see decimal, rational, etc).

Not using getters and setters is a great way to end up with a spaghetti codebase where a variable is modified everywhere and no one knows what happens if they change something

@electrineer or... Make everything const? How does a get/set actually solve that data can be modified from lots of places? The problem is that you can set the data from lots of places, not how that's done.

@atheist well it doesn't if you provide both. At least it prevents burying a pointer to the variable in some struct. That will be very difficult to follow. Also, it makes it easier to find who does what, although that's not a huge benefit.

@electrineer that's simply not true. When you give get() and set() it's basically the same as exposing a field by making It public, only with 200% more noise and hard to read code.

@8lall0 think that's what they just said. 🤔

@electrineer and if you're using pointers in that way, it's plain simple code smell. Stop overcomplicating stuff and keep it simple.

@atheist it was only an example.

@atheist @8lall0 I was going for the exact same thing. high five with our pps!

I can only see two reasons for accessor methods without logic

1. Interfaces. Should be quite exceptional as interfaces are destined to just make do something but sometimes a property plays a role.
2. The language does not allow for transparent accessor logic and you are not in control of the code using the API. If you are in control you can just make the property private when logic is added. When not in control this is a breaking API change and in some cases this is either unacceptable or just unworkable (is the lib is highly model driven and had these changes often for example)