What is meant by “protection” in real OOP? | Hacker News Reader

What is meant by “protection” in real OOP?

5 pointstresilience8 comments

I read up on the history of Smalltalk and Object Oriented Programming, and one thing I have not quite grasped is the idea of "protection."

I know you can protect methods from being accessed by making them private or protected in certain programming languages but something else must be meant here.

Do you protect objects from being changed? Do you protect them from being "talked to" / responding with valuable returns to unauthorized requests / initial-message-senders? To what purpose?

And how exactly are they being protected, by what mechanism so to speak? (particularly in Smalltalk)

View on HN

Encapsulation[0] might be the term you are looking for. Enforcing object boundaries makes it easier to reason about program behavior and enforce security guarantees.

If objects can only change their own data, then all change affecting the object is either caused by the object itself, or indirectly by another when information crosses the interface the boundary presents (e.g. a message was received).

Most languages use a memory model that doesn't even have the concept of access rights, everything can potentially affect anything else. If your program has to be secure, this is a nightmare.

[0] https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...

Also interesting:

https://en.wikipedia.org/wiki/Message_passing

https://en.wikipedia.org/wiki/Capability-based_security

https://en.wikipedia.org/wiki/Agent-based_model

https://en.wikipedia.org/wiki/Actor_model

Thanks. I've read all links and I think I would like to see more hands-on code regarding to how this is done in the systems (like Smalltalk) itself.

There are two types of languages which use encapsulation: those who use it merely as the main syntactic model (C++, Smalltalk, Java, Python) and those who actually enforce it by managing memory access during runtime (E, Erlang).

The following might be intuitive https://raw.githubusercontent.com/erights/uploaded-papers/ma...

In Smalltalk, the only way how to communicate to objects is by sending messages. The way how they react on the messages is full the responsibility of objects, and they can refuse them. This decision is strictly late-bound because all message passing in Smalltalk is late-bound. You may say that all the methods in Smalltalk are "public", but it is not the very same meaning as in other languages.

The objects store the state in instance variables. You cannot access the instance variables of objects from outside of the object. All instance variables are "protected" in the terminology of C++.

> The way how they react on the messages is full the responsibility of objects, and they can refuse them.

Thereby any further protection is totally up to the programmer right?

Yes. It is actually very easy to extend Smalltalk to support private/protected methods (message bytecode based on the protocols, for example). But Smalltalk would need to do these checks in run-time because all message sends are late-bound.

Thanks! Can you point me to where I can find out more about the eval-"loop" that the entire Smalltalk runs on?

Check the Blue Book: http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....

Reply on news.ycombinator.com