On Wed, 22 Jun 2011 14:52:52 +0300, Peter Alexander
<peter.alexander...@gmail.com> wrote:
// module A
private class Foo;
public alias Foo[] Foos;
// module B
void main()
{
Foos fs; // Legal? Seems so.
Foo f = fs[0]; // Clearly can't use Foo here, it's private.
auto f2 = fs[0]; // Legal?
fs[0].memFun(); // Legal?
}
I don't think this is a big problem because both Foo and Foos are
defined/aliased by the library developer.
Similar reasoning would be applied to many other cases where a library
developer allows/disallows/does something that ends up with errors on the
user side, intended or not, competent or not.
Of course, the same problems arise if you alias something like Array!Foo.
Well, as long as Foo is private.
On Nick's example:
private class Foo {}
public bar(Foo f) {}
Just like the Foo/Foos example this is also entirely lib developers fault,
what is he thinking, and why is this enough? He could after all do
something like this and be done with it.
static this() {
unleash_hell();
}
So the difference between class aliasing and functional composition is
that class aliasing does not completely encapsulate the class, while the
function does. Function composition is more analogous to structural
composition.
In my opinion, it should be illegal to publicly alias a private type (or
any derivative type) because it introduces too many issues, as I have
demonstrated above.
The template example alone is enough of a reason to have this IMO.
