UFCS for D

Nick Sabalausky a at a.a
Thu Mar 29 18:57:11 PDT 2012


"Walter Bright" <newshound2 at digitalmars.com> wrote in message 
news:jl2um7$2eq5$1 at digitalmars.com...
> On 3/29/2012 5:09 PM, Steven Schveighoffer wrote:
>> The reason being, if you change anything in class A, you do not have to 
>> worry
>> about the implementation of getXSquared, because it simply has no access 
>> to the
>> private implementation. You only have to worry about internal methods, 
>> and
>> friend functions.
>
> Ok, I see what you're talking about. It has nothing to do with UFCS, it is 
> D's design decision to not have explicit friends, but to make everything 
> in a module implicitly a friend.
>
> I think it's far superior to the explicit friend thing in C++.
>
> I've never seen much cause for hiding things within the same module. It's 
> not like you're allowed to edit one part of the file and not touch another 
> part.

That's the *whole point* of moving it outside the class. (Well, that and a 
smaller vtable.)

In D, if you change this:

-----------------
// foo.d
class Foo
{
    [...core stuff...]
    void extraFunctionality() {...}
}
-----------------

To this:

-----------------
// foo.d
class Foo
{
    [...core stuff...]
}
void extraFunctionality(Foo f) {...}
-----------------

How the heck does that improve encapsualtion? With D's implicit friends, it 
*doesn't*, it's just shifting things around. There is NO encapsualtion 
benefit there. Like Steven said, to *get* the encapsualtion, you have to 
create a whole new module to stick "extraFunctionality" into.




More information about the Digitalmars-d-announce mailing list