On 22/06/11 1:41 PM, Nick Sabalausky wrote:
"Peter Alexander"<peter.alexander...@gmail.com> wrote in message
news:itsl71$1cnq$1...@digitalmars.com...
On 21/06/11 7:59 PM, Nick Sabalausky wrote:
"Peter Alexander"<peter.alexander...@gmail.com> wrote in message
news:itq945$2ag0$1...@digitalmars.com...
Is the following legal D?
// module A
private class Foo;
public alias Foo Bar;
// module B
import A;
Bar b; // I can't use Foo, but can I use Bar?
I'm adding module level protection for types into DMD and wondering if
this should be legal.
I'm no authority on this, but I'm pretty sure that's supposed to be
legal.
Access modifiers work non-transitively on just the given symbol. And it's
a
useful idiom in cases that are more complex than that (ex: Using a
templated
alias to provide a cleaner public interface to a private implementation
that
has a more complex interface).
Your code above is analogous to this, which *definitely* is supposed to
be
legal:
// module A
private foo() {}
public bar()
{
foo();
}
// module B
import A;
bar(); // I can't use foo(), but can I use bar(). Nothin' wrong with
that.
That is similar, but not analogous.
The problem arises when we come to more complex types:
// 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?
}
Of course, the same problems arise if you alias something like Array!Foo.
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.
That issue is not unique to alias:
private class Foo {}
public bar(Foo f) {}
Yeah, there's quite a few places where this crops up. Basically, I think
that private types (and related types, e.g. arrays of private types and
templates of private types) should be disallowed from appearing anywhere
in the public interface of a module. So that would include:
- aliases
- function arguments
- function return types
There's probably more places where we'd need to add checks.
