On Fri, 11 Feb 2011 17:26:29 -0500, Andrej Mitrovic
<andrej.mitrov...@gmail.com> wrote:
On 2/11/11, bearophile <bearophileh...@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
