Adding a new design constraint to D

[Paul Backus]

On Sunday, 19 June 2022 at 00:48:12 UTC, forkit wrote:
> Information hiding is central to the concept of a concrete 
> type, which in OOP, is what a class is -> a concrete type.
>
> OK. So how do you apply the principle of information hiding in 
> D. Well, you put the class that needs this, into it's own 
> module.
>
> Sure, you've now you've got a defacto means of hiding 
> information (since there's no other code in the module) - but 
> that comes at the cost of new design constraint that gets 
> imposed on you (one class per module, always, just as a defacto 
> means to make it into a concrete type).
>
> But this is not OOP. Lets be really clear about this.

It's funny that you say this, because this is exactly how 
information hiding works in the Common Lisp Object System:

> Like the OO systems in most dynamic languages, CLOS does not 
> enforce
> encapsulation. Any slot can be accessed using the slot-value
> function or via (optionally auto-generated) accessor methods. To
> access it via slot-value you have to know the name of the slot. 
> CL
> programmers use the language's package facility to declare which
> functions or data structures are intended for export.

Source: https://en.wikipedia.org/wiki/Common_Lisp_Object_System

A "package" in Common Lisp is more or less the same thing as a 
module in D: a namespace for symbol definitions.

If you are willing to bite the bullet here and say that CLOS is 
"not OOP" because it lacks encapsulation, then fair enough, but 
at that point I think you must admit that your idea of what 
counts as OOP is not shared by most developers (including Alan 
Kay himself, who cited Lisp as an example of OOP done right).