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.

@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

@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

@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

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

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

@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)