3 ms·

> [...] an interface boundary that leaks no state is possible to implement and can give freedom to the designer regarding internal state. Your suspicion is jus

by taffer 5y ago

> [...] an interface boundary that leaks no state is possible to implement and can give freedom to the designer regarding internal state. Your suspicion is justified. As long as the objects only send immutable messages to each other, encapsulation remains intact. But then you have something closer to an actor system than what people typically think of when they say OOP. Once you pass references to mutable objects, all bets are off. The ability to specify which states are allowed and which are not, is not a special feature of OOP. In the functional and relational paradigms, there are types and constraints that specify in a declarative way what states should be possible. Types and constraints are enforced by the runtime and are not based on (leaky) encapsulation.

baryphonic 5y ago
> But then you have something closer to an actor system than what people typically think of when they say OOP. This is fair. I tend to think of OO per Alan Kay's description, i.e. message passing, encapsulation and extreme late-binding.[0] That does look closer to actors or even FP than it does the so-called OOP languages, which is what most might think. > The ability to specify which states are allowed and which are not, is not a special feature of OOP. In the functional and relational paradigms, there are types and constraints that specify in a declarative way what states should be possible. Types and constraints are still code that are tightly bound to the data they describe (since in a real sense, they are executed, either at compile time or runtime, and the most powerful type systems are Turing complete). The data oriented advocates sometimes forget this when decrying code tightly coupled to data. As types and constraints are added to specify only the proper behavior, the data gains more signal and less noise, and thus becomes more like information and less like data. [0]http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

by taffer 5y ago

baryphonic 5y ago

> But then you have something closer to an actor system than what people typically think of when they say OOP. This is fair. I tend to think of OO per Alan Kay's description, i.e. message passing, encapsulation and extreme late-binding.[0] That does look closer to actors or even FP than it does the so-called OOP languages, which is what most might think. > The ability to specify which states are allowed and which are not, is not a special feature of OOP. In the functional and relational paradigms, there are types and constraints that specify in a declarative way what states should be possible. Types and constraints are still code that are tightly bound to the data they describe (since in a real sense, they are executed, either at compile time or runtime, and the most powerful type systems are Turing complete). The data oriented advocates sometimes forget this when decrying code tightly coupled to data. As types and constraints are added to specify only the proper behavior, the data gains more signal and less noise, and thus becomes more like information and less like data. [0]http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en