Inheritance problem

[Steven Schveighoffer]

On Fri, 11 Feb 2011 17:26:29 -0500, Andrej Mitrovic  
<andrej.mitrovich at gmail.com> wrote:

> On 2/11/11, bearophile <bearophileHUGS at lycos.com> wrote:
>> Steven Schveighoffer:
>>
>>> Any code can access any members defined in the current module,  
>>> regardless
>>>
>>> of access attributes
>>
>> I am not sure if Walter understands how much this rule makes it hard for
>> people not already used to protected/private attributes to understand  
>> and
>> learn to use those attributes correctly. The C# compiler doesn't have  
>> that
>> rule, and it's much more strict. I think this makes learning the usage  
>> of
>> those attributes faster.
>>
>> Bye,
>> bearophile
>>
>
> I think one benefit of the current approach is that we'll be able to
> use free functions which could be called as if they belong to a class
> (if they have that class as the first parameter), since we could use
> the uniform function call (UFC) syntax. But UFC doesn't work with
> classes yet, otherwise we might be able to do this:
>
> module foo;
> import std.stdio;
>
> class Foo {
>     private int _x, _y;
>     this(int x, int y) {
>         _x = x;
>         _y = y;
>     }
> }
>
> int sumXY(Foo foo) {
>     return foo._x + foo._y;
> }
>
> module main;
> import foo;
> import std.stdio;
>
> void main() {
>     auto obj = new Foo(10, 10);
>     writeln(obj.sumXY());  // using UFC, but doesn't work yet
>     //~ writeln(obj._x + obj._y);  // not allowed
> }
>

What's wrong with:

class Foo {
     private int _x, _y;
     this(int x, int y) {
         _x = x;
         _y = y;
     }
     int sumXY() {
         return _x + _y;
     }
}

> We could have a bunch of templated functions in the foo module which
> could work with any class inside that module. So it might help out
> against the common God class problem. What do you think?

I'm unaware of this problem, but I'm not sure it's a huge problem.  The  
UFC syntax is a marginal benefit, making a function look like it's part of  
the class.  The "horrible" alternative is to simply call the function with  
Foo as a parameter instead of the source.  i.e. f(x) vs. x.f()

Couldn't the same be achieved via mixins?  And in fact, the mixin I think  
can be defined in a separate module, more flexible.

-Steve