4 ms·

SELECT name FROM users; Users.getName(); The above is "encapsulated" meaning that you need to have done the extra work to write "getName". Encapsulation is a

• mlthoughts2018 8y ago
  Why wouldn’t encapsulation be linked more to normalization in a declarative setting? I’d argue that “implementation hiding” in a declarative setting is more about unfolding all data dependency, so that attributes are isolated from each other. Then the extra work to perform more joins to reproduce a cumulative data record seems very analogous to the extra work of getters and setters.
  • mjburgess 8y ago
    joining is connected to normalization, not to declarative style declarative style is (essentially) the highly polymorphic use of verbs in programming. You might even call it "polymorphic programming" rather than declarative, since that's often what is being prioritized. this level of polymorphism requires the data-operated-on by the verb to be relatively exposed ie., "select" cannot be different for every table OO essentially has "select" redefined every time you want to expose data.
    • mlthoughts2018 8y ago
      > “OO essentially has "select" redefined every time you want to expose data.” I still don’t see how this is different in concept, since you “redefine” selection every time for normalized attributes as well (you must individually hand-specify where to select from). I get what you’re saying about polymorphism, such that things like select or join “just work” on everything. Many OO / functional programming languages have that too, for example with __getitem__ or __getattr__ protocols in Python, so that the same “verb” (e.g foo.x = 3) “just works” automatically without concern of specialized implementations. But in the declarative case you’re just trading off the conplexity of creating and registering specific getter logic per each type against flattening out all the attributes such that all the complexity is embedded into knowing the correct name to ask for the universal verbs (e.g. select) to apply to.
      • mjburgess 8y ago
        > against flattening out all the attributes Hence the tension with encapsulation
        • mlthoughts2018 8y ago
          I don’t understand what you mean by “tension.” In an OO setting, you register specialized implementations with some type of interface / protocol / dispatcher. In functional programming you create functions that allow a data type’s specialized implementation to be type matched against a typeclass. In declarative programming you flatten out attributes so that a pre-existing set of polymorphic operators apply, and you translate the complexity of lookups (that match the implementation) into the complexity of specifying everything in a splayed-out form. It’s all the same complexity, just different trade-offs for how it’s represented. I wouldn’t describe this as “tension” because that makes it sound as though declarative programming has some fundamental limitation or missing capability regarding encapsulation, but it doesn’t. It’s just making a different trade-off of the same thing.
          • mjburgess 8y ago
            I guess there's two senses of "encapsulation" in use here. What I think is meant by the article is information-protection rather than information-hiding, or implementation hiding. Encapsulation in the sense of "private string name;".
• fnord123 8y ago
  >This "extra work" is in tension with a declarative approach No it isn't. They work complementary to each other. If User is an interface then retrieving the name could be a call to a db, read from a file, read in memory, http GET request, it doesn't matter. The declarative component here does not care how the request is fulfilled as long as the interface is respected.
  • 0815test 8y ago
    The problem is that encapsulation makes it hard to specify reasonable constraints. For example, a "getter" might come with a constraint that "x = myobj.GetX(); myobj.SetX(x);" should not change the observable behavior of myobj. Or that "myobj2.ConstructFromXY(myobj.GetX(), myobj.GetY());" should result in a "myobj2" that's in some ways indistinguishable from "myobj". With a "declarative" approach, these constraints are implied in the system itself.
• cy6erlion 8y ago
  High level languages should be designed for humans to use, Encapsulation gives humans a levels of abstraction.