Should alias expand visibility?
Nick Sabalausky
a at a.a
Tue Jul 27 11:33:10 PDT 2010
"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
news:op.vgh50ulqeav7ka at localhost.localdomain...
>
>> private void funcA() {}
>> public void funcB()
>> { return funcA(); }
>>
>> In that, funcA is supposed to be private, but funcB exposes it...But so
>> what? If you didn't want it exposed, you wouldn't have made funcB public.
>
> If you want it exposed, why not make funcA public? These simple examples
> are not compelling.
>
So you think that the funcA/funcB combination above should be disallowed?
That's the point I was making. If you feel that should be disallowed, then
we just simply disagree on a very fundamental level. If you don't think that
should be disallowed then I think you're viewpoint is self-contradictory.
As for the usefulness of providing public access to a private symbol
regardless of whether it's via alias or forwarding, see the "static if"
examples both Tomek and I provided. And as for why not keep all of those
public, there are perfectly legitimate real-world reasons to not want to do
that. The simplest probably being to keep a public interface free of
unnecessary clutter.
>
> (Yes, I did mean B : A, I always forget that!)
>
> So private int foo is now a virtual function? That seems very
> counter-intuitive.
>
I'd consider throwing away polymorphism just because one symbol was created
with an alias to be far more counter-intuitive. And I would also consider
disallowing a perfectly logical combination of visibility attributes and
alias to be more counter-intuitive.
More information about the Digitalmars-d
mailing list