4 ms·
The author's beef with encapsulation seems to be that when an object A is used as an argument in the constructor to object B, the latter needs to do a deep copy
by GFK_of_xmaspast 10y ago
The author's beef with encapsulation seems to be that when an object A is used as an argument in the constructor to object B, the latter needs to do a deep copy (as keeping a pointer is not "safe"), which is of course not always possible.
I'm at a loss as to what this has to do with encapsulation, and even less able to understand how any language with user-defined data types is going to be able to avoid it.
- huahaiy 10y agoLanguages with immutable data structures?
- astrange 10y agoOr linear types. Actually, immutable containers isn't good enough; you need all the leaves to be immutable too.
- jeremyjh 10y agoIt is a very abrupt dismissal along the lines of: encapsulation doesn't perfectly encapsulate, therefore it is useless. It is not perfect because the objects your class may encapsulate may have been passed in a constructor by reference, meaning there is code outside your class that can mutate those objects. Even in functional programming languages encapsulation is a useful concept - often in a functional language it is implemented with opaque data structures that can only be manipulated by the module which creates them (constructors are not exported). I don't think it always means there are not shared references; it all depends on the role of the data in question.