@immibis 1) True, but decisions of compiler designers would affect legal issues if my premise was true. 2) However, it looks like my premise is not true, because I believe those three lines are the exact "loophole" that I was after! Thanks! 3) True, although this makes it difficult to track down issues if software is released on dozens of platforms. Note: My question was strictly hypothetical and is just a strong curiosity of mine.

@RobertHarvey It may require you to think about legality in the way I have stated it, but if you define the assumption to the thought experiment as "you are not allowed to modify the library", then no legal thinking is required. It is then strictly a compiler / software design question.

Are we not allowed to ask hypothetical questions on here? I believe this is an issue which could have potential practicality.

I believe there is a fundamental misunderstanding here. Breaking encapsulation isn't illegal like stealing the gas out of my car. It's borrowing my car and bringing it back with fast food spilled all over the seats. Encapsulation has nothing to do with permission to modify, legal or otherwise. Breaking encapsulation IS immoral, not because you have no right to break it, but because when you do you create a mess that someone else has to clean up.

@CandiedOrange In the scenerio I've given, modifying and redistributing the library is illegal, and if modifying the library is the only way to break encapsulation, then breaking encapsulation would in fact be illegal. (However, immibis gave an alternative which falsifies this assumption.) As for the immoral point, that is an interesting one, but if you make sure to not create a mess that someone else has to clean up (e.g. by being the only developer on a project, by documenting your reasons for doing so, etc), I would argue it is not immoral.

Also I claim: There are scenarios in which breaking encapsulation is the one and only option without modifying the library. In fact, in practice there are many such scenarios. In an ideal world, maybe not, but proprietary codebases have internal workings, and sometimes these internal workings need to be tweaked slightly to achieve a result. This makes breaking encapsulation valid, since it is the only and therefore best option.

You're confusing encapsulation with security. Encapsulation isn't used to hide trade secrets. It's used to hide details that are annoying to look at. What you're talking about exists. It's just not called encapsulation.

No, of course I understand that encapsulation is for hiding internal workings of a class. In the follow scenario, what would you do? You're paid to develop a GUI frontend for a company's client that uses another company's proprietary <bridge vibration evaluator> or whatever. You finish the software, but the library was written by a British company which assumed that cars drive on the left side of the road.

You discover that you can get the cars to drive on the right side by setting the speed of the cars to a negative number by modifying the library and everything works fine, but the setSpeed() function throws an error when the speed is negative. You could ship the software within minutes if you could just set the private field directly, but the library must be distributed in original unmodified binary form. The deadline is two weeks away and the other company is not able to implement a setDirection() method in that time. What do you do?

I'd stop using libraries that prohibit modification. Or: AmericanCar inherits Car and now I can define setSpeed() to do whatever I want and I've modified nothing (and I've followed the Open/Closed Principle). Now I just have to paint my headlights red.

Two problems with your solution: 1) Switching libraries would take more than two weeks, if alternatives even exist, and 2) the field is private; subclasses cannot modify it. Sure, you could avoid the question, but I'm curious of a real solution here.

Hi, CandiedOrange. I want to make it clear that this is just a curiosity so I'm not strong-felt about a solution, just interested.

1) Switching libraries doesn't take two weeks if you don't use closed libraries to start with. 2) Once I inherit I decide what field setSpeed() modifies and it's as public or private as I want it to be.

I think the scale of the libraries is misunderstood here. This hypothetical library is the result of 6 years of research of bridge vibration technology and while there may be an alternative, it would require switching 1000 API calls and months of testing.

setSpeed() is public, but the _speed variable is private in the library's class. The class also uses _speed to set up many other classes it creates during simulation.

Don't care. All I need is a different car. If I can't plug in my own car to this library it's a crap library that didn't follow decent design principles like encapsulation.

That may be true, although I'd argue that a speed is all you need to set up vibrational mode parameters and stuff, not an expert in this example though. It seems like it would be silly to make an entire car subclass as the designer of the library if only the speed is needed.

But suppose this is the best library in the small field of bridge simulation. There are thousands of fields where only a single proprietary library exists. Not every application has 100 nice open source clean implementations of it in the real world.

True. But if you lie down with stray dog's don't act surprised when you come up with flees.

So you're avoiding the problem. What if you told your boss two weeks before the deadline that you needed a whole other library. That would be ridiculous.

The solution is simple: hack the header files, test that the compiler happens to make it ABI-compatible with the binary blobs, and ship the software. But for some reason, some C++ programmers take basic principals too strongly. Programming is an art, and rules are meant to be broken as long as you understand the consequences.

I'm saying you don't tell the boss you'll be done in two weeks until you know if your library is going to do this kinda thing to you. You never perfectly avoid all problems but you can go in with your eyes open an manage them.

Maybe so but if I did this the next release would be to undo this.

Exactly!

Because you don't want to have to repeat the process of checking the ABI every time you release.

As a software developer, I prefer flexibility, which is why I like C++. Actually I like C because it's the most flexible, but is so flexible in fact that it's hard to design things that need at least a little bit of structure, so C++ solves this problem.

But this issue with encapsulation sticks out like a sore thumb as one of the big inflexibilities of C++. You can do all sorts of pointer manupulation and cast const to mutable, etc, but you can't "cast" to private? Sounds imbalanced.

That's called technical debt. You can get quick wins by making a mess but soon there are no more quick wins because you're working in a mess. I work hard to avoid this for the same reason when I move furnature I try to plan things so I only have to touch things once. Moving the same thing twice sucks.

Yup, I too work hard to avoid technical debt, but I'm also aware of how to properly use it as a tool, in that same way that bank debt can sometimes be useful.

The most sinister thing about technical debt is it's so easy to pretend it's not a problem.

Also a problem with many people and bank debt!

yes it's an apt metaphor

"I don't have enough money, I'll just put it on a credit card." is similar to "We don't plan to continue hiring these people after they finish, so just make sure they deliver the software in any way possible."

But my argument is that time is sometimes more valuable than code quality, and you can make tradeoffs both ways.

If banks refused giving loans, that might be bad for you in this case. Similar to a library marking something as private, or more generally, the C++ language not allowing you to hack around it.

I think it's bizarre that const can be cast to mutable types in C++, but I'm glad it's there.

Anyway, good talking to you! I'm going to leave now.

l8r