4 ms·

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 pret

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

WalterBright 1y ago
#define duck_season wabbit_season #include "shoot.hpp"
n2d4 1y ago
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.
- NeutralForest 1y ago
  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.
  - jjice 1y ago
    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.
    - NeutralForest 1y ago
      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.
  - throwaway2037 1y ago
    > 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.
    - NeutralForest 1y ago
      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.
    - colejohnson66 1y ago
      Something something undefined behavior
- TylerE 1y ago
  That is absolutely a social construct and not a language feature. You can override “private” members just fine with a simple assignment.
- _ZeD_ 1y ago
  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
- masklinn 1y ago
  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.
jjmarr 1y ago
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 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.
leni536 1y ago
Don't do that in C++. Maybe unless if you are debugging. This can blow up in your face in unexpected ways.
ethan_smith 1y ago
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.
- CodeHz 1y ago
  Actually, it won't compile in msvc (the linking phase, to be precise), MSVC uses different names for methods with different visibilities
jmmv 1y ago
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.
colanderman 1y ago
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 https://stackoverflow.com/a/36149568 It will work until it doesn't.

WalterBright 1y ago

#define duck_season wabbit_season #include "shoot.hpp"

n2d4 1y ago

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.

NeutralForest 1y ago
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.
- jjice 1y ago
  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.
  - NeutralForest 1y ago
    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.
- throwaway2037 1y ago
  > 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.
  - NeutralForest 1y ago
    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.
  - colejohnson66 1y ago
    Something something undefined behavior
TylerE 1y ago
That is absolutely a social construct and not a language feature. You can override “private” members just fine with a simple assignment.
_ZeD_ 1y ago
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
masklinn 1y ago
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.

jjmarr 1y ago

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

leni536 1y ago

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

ethan_smith 1y ago

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.

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

jmmv 1y ago

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.

colanderman 1y ago

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 https://stackoverflow.com/a/36149568 It will work until it doesn't.