On Fri, Nov 02, 2018 at 12:25:21AM +0000, unprotected-entity via Digitalmars-d-announce wrote: [...] > "Encapsulation is sometimes referred to as the first pillar or > principle of object-oriented programming. According to the principle > of encapsulation, a class or struct can specify how accessible each of > its members is to code outside of the class or struct. Methods and > variables that are not intended to be used from outside of the class > .. can be hidden to limit the potential for coding errors or malicious > exploits." > > https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/
That is a narrow definition of encapsulation that is very OO-centric, and IMO, it sorta misses the larger point behind encapsulation, focusing instead on the mechanics of it, and that the specific implementation of it in the OO paradigm. The concept of encapsulation goes beyond OO and classes; it has to do with modularity and well-defined interfaces between modules (or units of encapsulation -- this is not necessary the same thing as a D module). It's fine to explain how OO's concept of classes and methods implement encapsulation, but to *define* encapsulation in terms of classes and methods is IMO missing the forest for the trees. If *that's* your basis for understanding encapsulation, it would it explain a lot of your reactions to this thread. But there is more to the world than the narrow realm of the OO paradigm, and in a multi-paradigm language like D, it doesn't seem to make sense to be handicapped by a definition of encapsulation that really only makes sense in the context of an OO language. What encapsulation is really about, is the ability to modularize your code into self-contained units which have well-defined interfaces, with private code and data that cannot be accessed outside of that unit. In OO languages, this unit would be the class. But in D, it's the module. That doesn't make D non-encapsulated; it just means we're using a different unit than an OO language. It's just a difference between pounds and dollars, not some fundamental discrepancy. You just have to convert one currency to another, that's all. > D simply has *zero* support for encapsulation of classes or structs, > within the module (only encapsulation from code that is outside the > module). > > Any programmers interested in enforcing encapsulation in D (the first > pillar of OOP), are *forced* (because the language doesn't provide the > tool to do anything else) to use the one class, one struct, per file > solution. Which seems really silly to me. D forces you into Java like > programming - just to encapsulate a little class or struct. > > Speaking of 'structs', I don't see anyone in the D community, telling > others to use 'one struct per module'. Because we love UFCS, and structs just lend themselves very well to that sort of usage. And along that line, recent wisdom is that it's better to move things *out* of classes (and structs) if they don't need access to private members. (Sorry, I wanted to include a link for this, but I couldn't find the article -- the title eludes me and google isn't turning up anything useful.) Class and struct APIs should be as minimal as possible -- just enough to do what needs to be done and no more, and the rest of the syntactic sugar (that makes it more palatable to your users) belongs outside as optional convenience functions. T -- There is no gravity. The earth sucks.
