Hacker News Reader

Comment by cherryteastain | Hacker News Reader

I agree that it's unnecessary, and Python's success despite not having private members/fields is testament to that. But public/private fields/methods, like pretty much everything in OOP, is a 'social' rather than engineering innovation. Just as a class tells you certain operations and data are inter-related, private methods or fields signal to a class's users that you probably will break things if you interfere with certain parts.

Otherwise, at least in C++, you can often bypass the private specifier without much difficulty. Perhaps the laziest and easiest way to do so is

    #define private public
    #include "foo.hpp"
    #undef private

View on HN

You should safely shoot yourself in the foot with `friend`, which is a core language feature for accessing private members/functions/etc.

https://www.cppreference.com/w/cpp/language/friend.html

Redefining public as private can violate the ODR rule and triggers undefined behaviour because private members are ordered in memory in an undefined way, while public members are ordered in a standard way.

Python absolutely does have private members. If a member starts with two underscores, its class name (and an underscore) is prefixed to the member name, essentially resulting in the same behavior as a private modifier. (Although there are ways to circumvent this in Python, there are also ways to access private fields in most other languages.)

But even if that were true, that wouldn't mean that accessibility modifiers are unnecessary in other languages. Python is a certain language with certain idioms, and other languages are more or less OOP and hence some constructs that might not make sense in Python definitely make sense elsewhere.

I see what you mean what I wouldn't really qualify name mangling as private members, you're discouraged to access them but you can access them all the same.

I'd consider it the same, personally. It's a social contract that you can absolutely break if you want, just with a bit of work.

Less work in Python than it is Java, but there are ways to get to them in Java, or hell, just modify the source and change it directly. By doing that, you're doing something the developer didn't intend and you shouldn't be surprised if it doesn't work at some point in the future. Same as I'd expect in the Python case.

Sure, I think the bar to modify is higher in Java for example but I can't really find fault in what you're saying because I'd never unknowingly modify a member with double underscores in Python.

    > but you can access them all the same

Can't you do the same in C++ using struct offsets and reinterpret_cast<>? I'm not sure what you are saying here.

I'm not familiar with C++ enough to know about circumventing `private` but in Python you can access "private" members just like any other "public" ones, with the dot notation. There's no specific enforcement at the language level, no error will be thrown.

Something something undefined behavior

That is absolutely a social construct and not a language feature. You can override “private” members just fine with a simple assignment.

No, it doesn't: double underscore field names are mangled basically to avoid easy overriding in su classes; keep in mind that it is a feature that predates super() in almost any form

Not only are those not technically private, they were never intended for information hiding in the first place. Name mangling was introduced to avoid namespace conflicts in inheritance scenarios.

#define duck_season wabbit_season

#include "shoot.hpp"

The #define private public hack doesn't work reliably in modern C++ compilers and violates the One Definition Rule, potentially causing undefined behavior and hard-to-debug errors.

Actually, it won't compile in msvc (the linking phase, to be precise), MSVC uses different names for methods with different visibilities

I’ve seen a ton of this “#define private public” in a previous team that was forced to write unit tests in a rush due to the whims of leadership. It hurt to see, and the resulting white box tests were useless.

That #define trick is not valid due to how C++ groups members of different visibility classes together. See e.g. https://stackoverflow.com/a/36149568 It will work until it doesn't.

Don't do that in C++. Maybe unless if you are debugging. This can blow up in your face in unexpected ways.

Reply on news.ycombinator.com