UFCS for D

[Nick Sabalausky]

"Walter Bright" <newshound2 at digitalmars.com> wrote in message 
news:jl3kkf$j4b$1 at digitalmars.com...
> On 3/29/2012 6:57 PM, Nick Sabalausky wrote:
>> 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.
>
> It doesn't improve intra-module encapsulation, you're right. The point of 
> UFCS, however, is so that *other* modules can extend a class's methods 
> without breaking encapsulation.
>
> In D, the module is the fundamental unit of encapsulation, not the class. 
> The reason is the whole reason that friends exist - sometimes, more than 
> one component (i.e. class) is needed to manipulate private state.

(Disclaimer: I don't really excpect this to actually get changed at this 
point, just discussing.)

I definitely agree with this:

"sometimes, more than one component (i.e. class) is needed to manipulate 
private state"

However, that need could also be served by a "module" access specifier 
(similar to "package"). Personally, I think that would have been a better 
approach. (And it would still be much, much better than "friend".)

While there are definitely times I need to access private state across 
separate components within a module, I find such cases are fairly uncommon, 
so I question the wisdom of making it the default behavior.