This issue is a bit like premature optimization. One should not get dogmatic but be pragmatic. Some choices are important to get right early, others are not, and we should not waste time over-engineering what could be simple solutions.
I disagree even for models like point or vector. Even if their field doesn’t change the way you are working with them might change any time.
I used to buy into that line of thinking years ago, because the object-oriented programming Gods told me so. But at some point this thinking becomes a cargo cult. It does not align with reality.
I have been a programmer for over 25 years now, and I have yet to change how I interact with a trivial class such as a Point or Vector class. I have worked on code based with 3 million lines with history back to the early 1990s. There are no cases there either where these kinds of classes get changed.
At some point one has to take ones nose out of the object-oriented cargo cult books and actually look around at reality, and build your software based on how the real world works.
The creators of Go, fully realized this. Look at their code. It has been around quite some time now. Lots of fields are simply exposed and not encasulated. It has not caused them any problems.
What you actually need there is language support to create properties automatically.
No you don’t. You just need a language where the difference between a public field and a property can be hidden. Many languages are like that. In Swift a public field and a property looks the same. So no need to prematurely create a property.
But in Python and Julia you can easily turn a field into a function call after the fact if you want to. There is no need to create setters and getters ahead of time. That would be premature encapsulation, a wasted effort and unnecessary compliation of your code.
Consider an abstract to create some animations. You get an requirement to create a special mode when any modification of any object is logged in details.
That is nuts. You don’t want to add such change to basic types which could be used all over your code not related to animation. Separation of concern is an important software engineering principle you are ignoring here. You don’t want to embed knowledge about animation systems in a basic class.
The correct way to solve such problem is to change the animation system to accept new types of objects which embed your basic types. It would be very bad software engineering to begin modifying basic types, to fit an animation system. These basic types may be in a separate library used in other software packages you build, which suddenly get an added dependency to an animation system!
sorry it might sound like I am changing my mind halfway throgh the comment but it is my exact thought process while writting this post so I decided to leave it as is
Then I must apologize for writing this sort of rebuttal without reading to the point where I realize you basically agree with them 😏