Do non-member functions improve encapsulation in D?
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
Mon Apr 21 08:08:49 PDT 2014
On Mon, 21 Apr 2014 11:02:14 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> On 4/21/14, 1:49 AM, Lars T. Kyllingstad wrote:
>> On Sunday, 20 April 2014 at 20:36:58 UTC, Andrei Alexandrescu wrote:
>>> On 4/20/14, 12:11 AM, Lars T. Kyllingstad wrote:
>>>> The fact that "private" really means "module private" in D means that
>>>> any number of functions can break when a class/struct implementation
>>>> changes.
>>>
>>> No, only those in that module. There's no change. -- Andrei
>>
>> Ok, so "any number" was poorly phrased. What I meant was "a large
>> number", because in my experience, modules tend to be quite large.
>
> The point here is boundedness, i.e. whether stuff that's affected is
> within your control or not. The module you're working on is trivially
> "yours". Changes visible outside the module are "unbounded" because they
> affect present and future client code.
>
>> I often wish "private" meant class private in D.
>
> I think we're in good shape here.
Sure, but Lars' point that it completely precludes the encapsulation
mechanism that Scott is advocating, is true. You would have to put the
functions outside the core module to give them the same isolation as
non-friend C++ global functions.
Note, I'm with you that the current mechanism is the "right way." It just
completely prevents that technique of encapsulation :)
-Steve
More information about the Digitalmars-d
mailing list