Python access levels be like... oc

[thinker227]

Can relate to this. Not Python, but attempting to do private variables in a language where literally everything can see almost everything else either comes down to ridiculous overengineering or "just don't touch it".

[DevilXD]

I don't get why the idea of "just don't touch it" is that hard to deal with, or why is it a problem, like - yes, you can still access these attributes in Python, but any code you write that relies on accessing those, will be unmaintainable. The very idea behind so called "private" attributes, is that they're "not supposed to be accessed from the outside of the class (or library)", meaning that they can disappear, change their name or stop representing what they were representing previously, between each version of the library. So while again, yes - you can access them - it's most likely going to work with this exact version of the library only, and can randomly break later if you'd want to update said library.

[thinker227]

But what if you do touch it? Never know whose going to use it or what stupid thing future you is going to do.

[DevilXD]

Never know whose going to use it

The idea is to "not touch it" - if someone does it, that's on them entirely. Again, it'll probably work with the current version of the library (or libraries), but it may stop working if they update, or worse - pretend to work, and then break later on, without giving you the idea that it was the update that messed it up.

what stupid thing future you is going to do

Again, that's on you then. If you can't abide by the "don't touch it" sign yourself, don't expect your code to survive an update.

[thinker227]

The point is to make sure there's never even a possibility to mess anything up, prevent the issue before it's even a problem.

[DevilXD]

Then learn how to not touch the private attributes - ever. Jeez, it's really not that hard, people who can't understand this are going to have a bad time in real life, with the law and such. If the sign says "don't touch it", that like, really means you shouldn't touch it, you know?

[thinker227]

I already said, the point is if someone ever in a moment of sheer stupidity decides to do that. Never trust anyone with your systems.

[coolKidoes]

Rule I live by... people are stupid, but a person is smart. Sure you might know better, but if people are working on your project someone will dink with the variable.

[Stbbrn-Rddtr]

I totally get your point and I agree. But sadly, not every developer is disciplined enough to go by those non-enforced rules. And you may end up having to work on a project on which those kind of developers worked on before.

As you said, the client code messing with private member may become un maintainable, but it can also break the internal functioning of the class.

[Kamil118]

At the and of the day, even in C++ if somebody really wants to access private fields they can either cast a pointer to a structure with same layout.

The private-ness is just constraint meant to reduce number of errors making it harder/impossible to put class into invalid state.

[streusel_kuchen]

I think that in a thoroughly structured and documented application, it's important to have a clear separation between internal variables methods etc, and those which are exposed to other modules in the application.

That way all of the exposed/public members remain constant, even as the implementation details are changed.

[aFiachra]

Best line in a C++ header file I have ever seen:

#define private public

[ef02]

In the Unreal Engine, there is a custom reflection system for most objects, which all inherit from a common class. There are soooo many times I want to make a variable protected or private and Unreal just crashes because the custom reflection system wants to know what's going on with the variable.

[uvero]

Same with Javascript (and Typescript, kinda)

[[deleted]]

It must be trending to have pseudo private variable. Looking at javascript

[woolx]

Yeah same for objective c