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