"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message
news:op.vgg66qezeav...@localhost.localdomain...
> On Mon, 26 Jul 2010 17:42:53 -0400, Tomek Sowinski <j...@ask.me> wrote:
>
>> W dniu 26.07.2010 22:56, Nick Sabalausky pisze:
>>>
>>> I disagree. I think it's perfectly rational. Perhaps a better example
>>> than
>>> the above:
>>>
>>> private void foo_implA() {...}
>>> private void foo_implB() {...}
>>> private void bar_implA() {...}
>>>
>>> static if( isDerpDerpDerp )
>>> {
>>> public alias foo_implA foo;
>>> public alias bar_implA bar;
>>> }
>>> else
>>> {
>>> public alias foo_implB foo;
>>>
>>> // If isDerpDerpDerp isn't true, then 'bar' is logically equivilent
>>> // to the faster foo_implB, so just use that:
>>> public alias foo_implB bar;
>>> }
>>>
>>> I see no reason to disallow something like that.
>
> But do you see the problem? The *alias* is public, but the *function* is
> private. To me it looks like, "here's a public name for my private
> function" I don't think it makes the function public, just the name, which
> doesn't make any sense. IMO, all three impl should be public if you want
> them to be callable.
>
I'm not sure that's a valid argument, because the same argument could be
made for function forwarding:
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.
Likewise, If I say "public alias xxx yyy;" I'm saying that I *do* want
expose xxx publically through the name yyy.
The thing is: "private" has never meant "this can never be accessed from the
outside". It has always just simply meant "this can never be accessed from
the outside *through this particular member/identifier/whatever*".
And it doesn't even have to be function forwarding, it could just be two
references to the same object.
>
> Again, I don't see the problem in making byColumns and byRows public. If
> that's not an option, you can always wrap, and rely on inlining (well,
> hopefully when inlining is good enough). I just don't see this as being
> something that's of enough use to justify a compiler change.
>
Hmm, again I see it differently: If that's the effect I want, why should I
have to go through the bother wrapping and inlining when the language
already has "alias". Besides, your argument here could be applied to the
idea of removing many other uses of alias, if not removing alias entirely.
>
> But a public alias to a private function to me is worthless. The function
> must be kept private, because that was the intention of the author.
>
I think my function forwarding argument above serves as a strong
counter-argument to this.
>> Can anyone give a good counter-example when a public alias of a
>> non-public symbol is evil?
>
> How about this one:
>
> class A
> {
> private int foo() {};
> public alias foo bar;
> }
>
> class B
> {
> public int bar() {};
> }
>
> A a = new B;
> a.bar(); // What should this call?
>
Assuming you meant "class B : A", I'd say that should have identical
semantics to (That is, of course, identical semantics with the obvious
exception being the result of "&A.foo == &A.bar"):
class A
{
private int foo() {}
public int bar() { return foo(); }
}
class B : A
{
public int bar() {};
}
A a = new B;
a.bar(); // What should this call?
Which would be a compile-time error because B is overriding A.bar without
using the "override" keyword. If you added "override" to B.bar, then B.bar
should be called.
