On Tue, 27 Jul 2010 01:01:44 -0400, Nick Sabalausky <a...@a.a> wrote:
"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(); }
But the compiler can understand that. I think when you use an alias, the
compiler treats it like you typed the other name. This can be seen in
ddoc, when you use an aliased type, ddoc shows the type you aliased, not
the type you wrote. I think this would require a huge change to the
compiler, for very little benefit.
And usually there are reasons you want to use private functions. This
doesn't seem to have a reason. Why not just call funcA funcB? There are
better ways to rename functions.
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.
And it doesn't even have to be function forwarding, it could just be two
references to the same object.
And why would you have one of those references be private? I don't
understand that aspect of it.
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.
Alias is good for renaming public functions without overhead. But
renaming private functions doesn't make any sense, you are the only one
calling them, why do you need to name them differently? If it should be a
public function named x, why does it also need to be a private function
named y?
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.
I withdraw that argument ;) I think the better argument is that it serves
no purpose to have a private alias to a public function. You can just as
easily call the public function.
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.
(Yes, I did mean B : A, I always forget that!)
So private int foo is now a virtual function? That seems very
counter-intuitive.
-Steve
