4 ms·

I don't think we can dispense with encapsulation and still have OO, though. Sure you can program without it. You can even make good programs without it. You

I don't think we can dispense with encapsulation and still have OO, though. Sure you can program without it. You can even make good programs without it. You may even be able to make better programs without it :-) However, it won't be OO. The idea behind OO is to move away from data-centric programming. If I have a system dealing with geometry, I can have a Point object that has an x and y coordinate. However, once I have a Point, I should be trying to make my system so that I no longer access x and y directly. X and y are "encapsulated" in the Point. Collaborators should use the functionality on Point to do what they need to do, rather than trying to pry Point apart and get at the data. Of course, barely anybody writes "OO" code like that, even if they espouse to follow "encapsulation". I would argue as well that generic functions do not, in themselves offer an OOP environment. You need one more thing: partially applied functions. If you can create a partially applied function, you can bake in some program state and pass it around, offering functionality on that program state. However, nobody on the outside can access that state. This is the encapsulation necessary for OO.

deleted 7y ago
[deleted]
jnwatson 7y ago
Python is build entirely around the idea that encapsulation is mostly useless. "We're all consenting adults" is the general philosophy. As long as there's a convention as to what properties are "public" and which are not, a motivated user of a class should be able to do what they want with it. There's no point in putting a "private/public/protected" security model in a programming language. It isn't a security boundary. This vastly simplified the design of OO in Python, and it makes testing far far easier. There's no need to go through the dependency injection acrobatics in order to change one method for testing or proxying. (There technically is a way to munge a property name in Python but its use is discouraged).
- scarface74 7y ago
  There's no point in putting a "private/public/protected" security model in a programming language. It isn't a security boundary. It’s about intention. If I mark a property or method as private, it means that I can get rid of it, rename it or change the expected behavior without considering it a breaking chance.
  - kevin_thibedeau 7y ago
    YAGNI rules the day.
    - scarface74 7y ago
      You’ve never had to refactor code that was used as a library by other developers? Do you realize how many hacks is built into Windows just because developers were using undocumented features?
  - marcosdumay 7y ago
    Yeah, and Python has some standard nomenclature for marking a property as protected and a little bit of behavior for helping mark it as private. You do not need encapsulation for that.
    - scarface74 7y ago
      And there is nothing about the Pythom runtime stopping someone from using it anyway. With a statically typed language, you really have to go out of your way to do it like using reflection and if your code breaks on an update you get what you deserve.
- deleted 7y ago
  [deleted]
- mschuetz 7y ago
  I wish there was a "do not touch unless you know what you're doing" field. Private fields and members are a nuisance if you need to do some unsupported thing with a library. On the other hand, there are often utility functions in an object that are absolutely only ever meant to be used by that object itself, and not to be called from the outside.
  - zeveb 7y ago
    Python supports those by prefacing with "__", IIRC.
- arunix 7y ago
  > (There technically is a way to munge a property name in Python but its use is discouraged). Do you have a reference for that (i.e. the discouraged part)?
hnick 7y ago
I'm pretty sure Perl's Native OO has no encapsulation, at least without custom modules or weird wranglings like inside-out objects. It doesn't mean we must peek inside, but the option is there. It is completely functional, but as prone to misuse as the rest of Perl.
- lizmat 7y ago
  One should note that in Perl 6, object encapsulation is complete. You can only directly access attributes inside a class, and only through (usually autogenerated) methods outside of it.
ken 7y ago
Point = {x, y} is a strange example. What exactly is being encapsulated? Any Point structure I've ever seen has accessors for x and y, and no other internal data. In general, I don't see the need for encapsulation in order to qualify for object status. The classic counterexample is CLOS, which doesn't have it -- and the debate over that has been raging for decades [1]. [1]: http://wiki.c2.com/?HowObjectOrientedIsClos http://wiki.c2.com/?HowObjectOrientedIsClos The best basis for the essence of object-orientedness that I ever read was suggested in an article that focused on identity. (I don't remember where I saw this -- possibly from Kent Pitman?) If you could guarantee that some value is exactly the same as a value that you had earlier, and not just a mostly-copy but identical in every respect, then you had an object. Everything else falls out of that.
- BurningFrog 7y ago
  The Point could internally be represented in a polar coordinate system. I kind of agree that encapsulation isn't needed for object status. The caveat only being that it would be a weird object system where you could be sure there was no encapsulation. I mean, OK, in some languages you know that. But does it change anything important? https://en.wikipedia.org/wiki/Polar_coordinate_system https://en.wikipedia.org/wiki/Polar_coordinate_system
  - kazinator 7y ago
    Even if a point uses polar coordinates internally, we can have syntax "p.x" which gets the Cartesian x. Information hiding is an important concept in low-level-ish systems programming languages in which p.x implies a piece of machine code that offsets 24 bytes from the base address of p, and fetches a four byte integer.
- mikekchar 7y ago
  This is a great question. I thought that myself, so I tried to make a system where I couldn't access x and y. It turns out it's completely reasonable to do so. If you want to move a point, you add a translate method. If you want to compare points you can. You can add and subtract points. If you want to align a group of points on the X access, you can write a method on point to do it. There were very few times when I wanted to actually access x and y rather than act on it. I do agree, though, nobody actually writes code like that. Does that mean that I think nobody actually does OO? I hadn't actually thought it through that far :-) I think this is why the concept is so vague (your excellent example being a great indicator of that). C++ is often referred to as "C with Objects" and I sometimes think we've gone so far as to say anything with a function that operates on a structure is "Object Oriented". If so, I think we've lost our path a little bit.
kazinator 7y ago
Note that "encapsulation" refers to two completely different things, one of them by mistaken application of the word: - combination of methods and data - information hiding Information hiding is needed for OOP, but it can be hidden in the implementation. The fact that if I have a point object, I can access point.x is not an example of information hiding being violated. Firstly, it doesn't interfere with polymorphism: the same point.x code can access the x coordinate of points of different types. Secondly, the syntax point.x can actually be a method call which invokes an accessor under the hood, so the object doesn't actually have to have a slot x. There is no semantics or "moral" difference between having a pair of methods point.getx() and point.setx(<number>), and just a point.x. Lastly, sometimes it is perfectly acceptable in an object design to have trivial properties. Information hiding is more important in languages like C++ because an access like "point.x" compiles to code which assumes that x is at a particular offset in that object, and is of a particular type and so forth. It's less important in a dynamic language in which we can cafely ask for the x slot of any object. Encapsulation of methods and data isn't required in an OOP system; OOP systems like CLOS work without it just fine.

deleted 7y ago

[deleted]

jnwatson 7y ago

Python is build entirely around the idea that encapsulation is mostly useless. "We're all consenting adults" is the general philosophy. As long as there's a convention as to what properties are "public" and which are not, a motivated user of a class should be able to do what they want with it. There's no point in putting a "private/public/protected" security model in a programming language. It isn't a security boundary. This vastly simplified the design of OO in Python, and it makes testing far far easier. There's no need to go through the dependency injection acrobatics in order to change one method for testing or proxying. (There technically is a way to munge a property name in Python but its use is discouraged).

scarface74 7y ago
There's no point in putting a "private/public/protected" security model in a programming language. It isn't a security boundary. It’s about intention. If I mark a property or method as private, it means that I can get rid of it, rename it or change the expected behavior without considering it a breaking chance.
- kevin_thibedeau 7y ago
  YAGNI rules the day.
  - scarface74 7y ago
    You’ve never had to refactor code that was used as a library by other developers? Do you realize how many hacks is built into Windows just because developers were using undocumented features?
- marcosdumay 7y ago
  Yeah, and Python has some standard nomenclature for marking a property as protected and a little bit of behavior for helping mark it as private. You do not need encapsulation for that.
  - scarface74 7y ago
    And there is nothing about the Pythom runtime stopping someone from using it anyway. With a statically typed language, you really have to go out of your way to do it like using reflection and if your code breaks on an update you get what you deserve.
deleted 7y ago
[deleted]
mschuetz 7y ago
I wish there was a "do not touch unless you know what you're doing" field. Private fields and members are a nuisance if you need to do some unsupported thing with a library. On the other hand, there are often utility functions in an object that are absolutely only ever meant to be used by that object itself, and not to be called from the outside.
- zeveb 7y ago
  Python supports those by prefacing with "__", IIRC.
arunix 7y ago
> (There technically is a way to munge a property name in Python but its use is discouraged). Do you have a reference for that (i.e. the discouraged part)?

hnick 7y ago

I'm pretty sure Perl's Native OO has no encapsulation, at least without custom modules or weird wranglings like inside-out objects. It doesn't mean we must peek inside, but the option is there. It is completely functional, but as prone to misuse as the rest of Perl.

lizmat 7y ago
One should note that in Perl 6, object encapsulation is complete. You can only directly access attributes inside a class, and only through (usually autogenerated) methods outside of it.

ken 7y ago

Point = {x, y} is a strange example. What exactly is being encapsulated? Any Point structure I've ever seen has accessors for x and y, and no other internal data. In general, I don't see the need for encapsulation in order to qualify for object status. The classic counterexample is CLOS, which doesn't have it -- and the debate over that has been raging for decades [1]. [1]: http://wiki.c2.com/?HowObjectOrientedIsClos http://wiki.c2.com/?HowObjectOrientedIsClos The best basis for the essence of object-orientedness that I ever read was suggested in an article that focused on identity. (I don't remember where I saw this -- possibly from Kent Pitman?) If you could guarantee that some value is exactly the same as a value that you had earlier, and not just a mostly-copy but identical in every respect, then you had an object. Everything else falls out of that.

BurningFrog 7y ago
The Point could internally be represented in a polar coordinate system. I kind of agree that encapsulation isn't needed for object status. The caveat only being that it would be a weird object system where you could be sure there was no encapsulation. I mean, OK, in some languages you know that. But does it change anything important? https://en.wikipedia.org/wiki/Polar_coordinate_system https://en.wikipedia.org/wiki/Polar_coordinate_system
- kazinator 7y ago
  Even if a point uses polar coordinates internally, we can have syntax "p.x" which gets the Cartesian x. Information hiding is an important concept in low-level-ish systems programming languages in which p.x implies a piece of machine code that offsets 24 bytes from the base address of p, and fetches a four byte integer.
mikekchar 7y ago
This is a great question. I thought that myself, so I tried to make a system where I couldn't access x and y. It turns out it's completely reasonable to do so. If you want to move a point, you add a translate method. If you want to compare points you can. You can add and subtract points. If you want to align a group of points on the X access, you can write a method on point to do it. There were very few times when I wanted to actually access x and y rather than act on it. I do agree, though, nobody actually writes code like that. Does that mean that I think nobody actually does OO? I hadn't actually thought it through that far :-) I think this is why the concept is so vague (your excellent example being a great indicator of that). C++ is often referred to as "C with Objects" and I sometimes think we've gone so far as to say anything with a function that operates on a structure is "Object Oriented". If so, I think we've lost our path a little bit.

kazinator 7y ago

Note that "encapsulation" refers to two completely different things, one of them by mistaken application of the word: - combination of methods and data - information hiding Information hiding is needed for OOP, but it can be hidden in the implementation. The fact that if I have a point object, I can access point.x is not an example of information hiding being violated. Firstly, it doesn't interfere with polymorphism: the same point.x code can access the x coordinate of points of different types. Secondly, the syntax point.x can actually be a method call which invokes an accessor under the hood, so the object doesn't actually have to have a slot x. There is no semantics or "moral" difference between having a pair of methods point.getx() and point.setx(<number>), and just a point.x. Lastly, sometimes it is perfectly acceptable in an object design to have trivial properties. Information hiding is more important in languages like C++ because an access like "point.x" compiles to code which assumes that x is at a particular offset in that object, and is of a particular type and so forth. It's less important in a dynamic language in which we can cafely ask for the x slot of any object. Encapsulation of methods and data isn't required in an OOP system; OOP systems like CLOS work without it just fine.