Sealed classes - would you want them in D?
KingJoffrey
KingJoffrey at KingJoffrey.com
Tue May 15 05:04:56 UTC 2018
On Tuesday, 15 May 2018 at 04:22:30 UTC, Mike Parker wrote:
> On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
>
>>
>> - Object independence
>> - Do not violate encapsulation
>> - Respect the interface
>
> This is what I don't get from your position. What is
> encapsulation? Here's what Wikipedia says [1]:
>
> "Encapsulation is used to hide the values or state of a
> structured data object inside a class, preventing unauthorized
> parties' direct access to them. Publicly accessible methods are
> generally provided in the class (so-called getters and setters)
> to access the values, and other client classes call these
> methods to retrieve and modify the values within the object."
>
> This has been my understanding of encapsulation since I first
> learned of it years ago. How is this broken in D? Only if you
> insist on viewing it in a strictly theoretical sense. As a
> matter of practical reality, it is not broken.
>
> If you have access to the internals of the class, you also have
> access to the rest of the module. No client of the class
> outside of the module has any access to the implementation. I
> showed you an example earlier of how silly it would be to force
> the rest of the module to use some sort of "module private"
> interface.
>
> The class in D *is* encapsulated. The interface *is* respected.
> I'm not sure what you mean by object independence.
>
>
> [1]
> https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
Yes, it's a vague word which can be interpreted different ways.
I primarily mean the more abstract notion of 'boundaries' and
'interfaces'.
The concept is well presented in this keynote at ACCU 2018:
https://www.youtube.com/watch?v=IP5akjPwqEA
E.g. passing from one room to another, via a door. The door
presents the boundary, and the interface through which you access
each room. You cannot go star trek style (yet) and just beam from
one room to the other.
'Beam me up scotty' is just for the movies (as far as I know ;-)
Also, if there is no boundary between the orange room and the
blue room, how would I get from the orange room to the blue room
- or vica versa?
The only reality our brains can perceive, is the reality made of
from boundaries and interfaces. We cannot hold all of reality in
our head. We have to break things down into little self-contained
chunks, and then understand how the chunks connect together.
It becomes particularly important when trying to understand
complexity (of any kind).
943294432432812 // grr!
943_294_432_432_812 // nice
the underscore represent the boundary.
the information between boundaries is now encapsulated (because
of that boundary)
Now, back to D...
in this example code below, the D module does not respect the
boundary of the object.
That is, the module can beam into the object without going
through the interface.
I struggle to understand why the module is allowed to do this - I
really cannot get my head around any valid reason for it - I'm
just getting told, 'that's how D does it' -or - 'it doesn't
really bother us'.
If I cannot control the interface, and have that respected by the
module, then this allows the kind of bugs that actually lead me
to working out that private is not really private at all.
And that bug would not have happened in C++/Java/C# - or, as far
as I know, Rust and Go. They would have all respected the
boundary.
D has chosen to allow the module to disrespect the interface. Why?
(and don't tell me it does - cause the code below clearly
demonstrates that it does not)
=======
module test;
void foo()
{
Person p = new Person("King Joffrey");
// this completely bypasses my interface
// (i.e. the boundary that I set up between the class and the
module)
p._name = "New King";
}
class Person
{
private string _name;
public void setName(string name)
{
this._name = name;
}
public this(string name)
{
_name = name;
}
}
================================
More information about the Digitalmars-d
mailing list