Extending D's support for object-oriented design with private(this)

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sat Apr 27 01:41:54 UTC 2024


On Friday, April 26, 2024 7:18:38 PM MDT zjh via dip.ideas wrote:
> On Friday, 26 April 2024 at 16:38:54 UTC, Steven Schveighoffer
>
> wrote:
> > I don't find the arguments compelling enough to make this new
> > feature. An entire module is as examinable as an entire class
> > definition. It's already open in your editor even.
> >
> > -Steve
>
> Although `the feature` is small,but  this feature is `harmless`
> and `many people` need it! Is this reason sufficient?

There is no question that some people want the feature, but a number of us
do not buy the idea that anyone needs it. It adds further complication to
the language (and personally, I don't want to see any more bugs related to
visibility attributes), and the value that it adds is highly questionable.

For many of us, experience has shown that something like private(this) is
completely unnecessary and that private as it works now is plenty. If a
struct or class really needs to keep its data private from any other piece
of code, it (or the other code) can be put into a separate module. And if a
module is large enough that you have to be worried about whether code
accesses a type's private members when you don't want it to, that module is
arguably too large anyway.

Arguably, if someone feels the need for something like private(this),
they're either doing something wrong, or they want it simply on the
principle that types should be able to prevent all code that's external to
them from accessing their private data. It really isn't an issue in
practice, and if you really want to ensure that code can't access a type's
private data, the workaround is simple.

What usually seems to happen with private is that most people who use D for
any real length of time have no problem with how it works, whereas folks who
are new to the language are sometimes initially confused and annoyed that it
doesn't work the way that they wanted or expected. They usually expect that
it would work like it did in whatever language they came from. So, they
either want private changed, or they want something like private(this)
added. Some people do continue to be annoyed about private long term, but
most developers seem to learn that it's really not an issue, and they're
fine with it.

If someone can come up with a particularly compelling argument such that it
convinces Walter, then we may end up with private(this) (or something
similar) at some point, but no one has yet come up with an argument that has
convinced him that anything like it is necessary, and in general, the folks
who have been around for a while tend to agree with him in this case.

Obviously, not everyone will agree, and we'll see what Walter says about
this proposal, but based on what he has said about this issue over the years
(including fairly recently), I would be very surprised if he decided to make
any changes to private or accepted a feature proposal like private(this).

- Jonathan M Davis





More information about the dip.ideas mailing list