So I know there are a lot of questions on getters and setters in general, but I couldn't find something exactly like my question.  I was wondering if people change the use of get/set depending on different languages.  I started learning with C++ and was taught to use getters and setters.  This is what I understand:
In C++ (and Java?), a variable can either be public or private, but we cannot have a mix.  For example, I can't have a read-only variable that can still be changed inside the class.  It's either all public (can read and change it), or all private (can't read and can only change inside the class).  Because of this (and possibly other reasons), we use getters and setters.
In MATLAB, I can control the "setaccess" and "getaccess" properties of variables, so that I can make things read-only (can directly access the property, but can't overwrite it).  In this case, I don't feel like I need a getter because I can just do class.property.
Also, in Python it is considered "Pythonic" to not use getters/setters and to only put things into properties if needed.  I don't really understand why its OK to have all public variables in Python, because that's opposite of what I learned when I started with C++.
I'm just curious what other people's thoughts are on this.  Would you use getters and setters for all languages?  Would you only use it for C++/Java and do direct access in MATLAB and Python (which is what I am currently doing)?  Is the second option considered bad?  For my purposes, I am only referring to simple getters and setters (just return/set the value and do not do anything else).
Thanks!
It's OK to have all public variables in any language. Yes, I know it's the opposite of what you learned.
OO theory says that there should be a public API that is stable, and private variables, where you can do whatever you want, and an implementation you can change to your hearts delight without changing the API.
And this is correct. But what is not correct is the idea that the private API must be made inaccessible from other classes. This is simply a mistake in the OO theory. It is an idea that sounds reasonable on paper, but in practice has little to go for it, but causes plenty of problems.
For example, many years ago I needed to subclass a widget in Delphi to make it behave slightly differently. Not a lot you see, just a bit. But the code I needed to override called a method that was private, so I couldn't override it. Instead I needed to override both methods. And of course, that other method did things that was really internal, so I ended up basically not subclassing the widget, but duplicating it, just because I did one small change.
OO theory claims this is how it should be, because horror of horror, maybe otherwise my sublclass might stop work with the next version of Delphi, if the superclass changes something internal! Well, so what? In that case I would just fix it.
It's my problem if I use parts of your internal data. You don't need to care. What you need to do is somehow flag that "This bit is internal and might change, use on your own risk". But when you as a developer of a library actively prevents me from using internal bits, you are only causing me problems.
I've now developed almost exclusively with Python for soon to be ten years, and the openness of Python has never caused me problems, and it fact has saved my ass several times (as I can fix framework bugs by simply patching in fixed code at runtime). Delphis standard OO model with different levels of protection caused me problems several times during the two years I worked with it.
The OO Theory is in fact wrong. There is nothing useful in having private members. Everything should be public. And that goes for any language, in my experience.
The use of getters and setters for different programming languages