www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should alias expand visibility?

reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
If foo is private but its public alias poo exists, should you be able to use 
poo? (currently you can't)


Tomek
Jul 25 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Tomek Sowinski" <just ask.me> wrote in message 
news:i2idhp$2jod$1 digitalmars.com...
 If foo is private but its public alias poo exists, should you be able to 
 use
 poo? (currently you can't)
I would think you should be able to (but I'm no authority on the issue).
Jul 25 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 25 Jul 2010 18:23:52 -0400, Tomek Sowiński <just ask.me> wrote:

 If foo is private but its public alias poo exists, should you be able to  
 use
 poo? (currently you can't)
I don't know, it'd be awfully messy, usually people keep it private. -Steve
Jul 26 2010
parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Steven Schveighoffer wrote:

 On Sun, 25 Jul 2010 18:23:52 -0400, Tomek Sowiński <just ask.me> wrote:
 
 If foo is private but its public alias poo exists, should you be able to
 use
 poo? (currently you can't)
I don't know, it'd be awfully messy, usually people keep it private.
What you mean by "awfully messy"? Compiler internals? I was asking for aliases and visibility because in my QuantLibD project I had this idea: struct PermutationMatrixExpr(Permutation permut) { static if (permut == Permutation.RowWise) { alias byPermutationDim byRows; alias byPermutationOrthoDim byColumns; } else { alias byPermutationDim byColumns; alias byPermutationOrthoDim byRows; } private: // Definitions for byPermutationDim & byPermutationOrthoDim } I don't want to expose byPermutationDim & byPermutationOrthoDim because the names are not understandable by wide audience. Sure, I could've used a one- line wrappers, but that means messier code, work for compiler to inline, debug mode runs slower, etc. Tomek
Jul 26 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 26 Jul 2010 13:59:42 -0400, Tomek Sowiński <just ask.me> wrote:

 Steven Schveighoffer wrote:

 On Sun, 25 Jul 2010 18:23:52 -0400, Tomek Sowiński <just ask.me> wrote:

 If foo is private but its public alias poo exists, should you be able  
 to
 use
 poo? (currently you can't)
I don't know, it'd be awfully messy, usually people keep it private.
What you mean by "awfully messy"? Compiler internals? I was asking for aliases and visibility because in my QuantLibD project I had this idea: struct PermutationMatrixExpr(Permutation permut) { static if (permut == Permutation.RowWise) { alias byPermutationDim byRows; alias byPermutationOrthoDim byColumns; } else { alias byPermutationDim byColumns; alias byPermutationOrthoDim byRows; } private: // Definitions for byPermutationDim & byPermutationOrthoDim } I don't want to expose byPermutationDim & byPermutationOrthoDim because the names are not understandable by wide audience. Sure, I could've used a one- line wrappers, but that means messier code, work for compiler to inline, debug mode runs slower, etc.
Sorry you had to go through that. My post was an attempt at dry humor ;) -Steve
Jul 26 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vggrccq3eav7ka localhost.localdomain...
 On Mon, 26 Jul 2010 13:59:42 -0400, Tomek Sowinski <just ask.me> wrote:

 Steven Schveighoffer wrote:

 On Sun, 25 Jul 2010 18:23:52 -0400, Tomek Sowinski <just ask.me> wrote:

 If foo is private but its public alias poo exists, should you be able 
 to
 use
 poo? (currently you can't)
I don't know, it'd be awfully messy, usually people keep it private.
What you mean by "awfully messy"? Compiler internals? I was asking for aliases and visibility because in my QuantLibD project I had this idea: struct PermutationMatrixExpr(Permutation permut) { static if (permut == Permutation.RowWise) { alias byPermutationDim byRows; alias byPermutationOrthoDim byColumns; } else { alias byPermutationDim byColumns; alias byPermutationOrthoDim byRows; } private: // Definitions for byPermutationDim & byPermutationOrthoDim } I don't want to expose byPermutationDim & byPermutationOrthoDim because the names are not understandable by wide audience. Sure, I could've used a one- line wrappers, but that means messier code, work for compiler to inline, debug mode runs slower, etc.
Sorry you had to go through that. My post was an attempt at dry humor ;) -Steve
Heh, now I get it too. Good one :)
Jul 26 2010
parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Nick Sabalausky wrote:

 Sorry you had to go through that.  My post was an attempt at dry humor ;)

 -Steve
Heh, now I get it too. Good one :)
Now me too:) But let's stay on the path: private void foo(); public alias foo goo; We gotta do something about this WTF. Either goo should be perfectly usable or the compiler shouldn't allow visibility expanding aliases. Which'd you pick? Tomek
Jul 26 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 26 Jul 2010 15:08:32 -0400, Tomek Sowiński <just ask.me> wrote:

 Nick Sabalausky wrote:

 Sorry you had to go through that.  My post was an attempt at dry humor  
 ;)

 -Steve
Heh, now I get it too. Good one :)
Now me too:) But let's stay on the path: private void foo(); public alias foo goo; We gotta do something about this WTF. Either goo should be perfectly usable or the compiler shouldn't allow visibility expanding aliases. Which'd you pick?
Serious now: Your simple example doesn't make any sense. Why wouldn't you just make foo public? If it's publicly accessible through an alias, it's publicly accessible. I don't buy the "too hard to understand" argument. Just don't document the "private" members :) IMO, protection attributes applied to an alias make no sense whatsoever. I don't think the above code should compile, except dmd accepts lots of noop attributes... Let me draw a parallel example: int x; const alias x y; // I want y to be a const view of x Does this make any sense? -Steve
Jul 26 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vggugam1eav7ka localhost.localdomain...
 On Mon, 26 Jul 2010 15:08:32 -0400, Tomek Sowinski <just ask.me> wrote:

 Nick Sabalausky wrote:

 Sorry you had to go through that.  My post was an attempt at dry humor 
 ;)

 -Steve
Heh, now I get it too. Good one :)
Now me too:) But let's stay on the path: private void foo(); public alias foo goo; We gotta do something about this WTF. Either goo should be perfectly usable or the compiler shouldn't allow visibility expanding aliases. Which'd you pick?
Serious now: Your simple example doesn't make any sense. Why wouldn't you just make foo public? If it's publicly accessible through an alias, it's publicly accessible. I don't buy the "too hard to understand" argument. Just don't document the "private" members :) IMO, protection attributes applied to an alias make no sense whatsoever. I don't think the above code should compile, except dmd accepts lots of noop attributes...
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.
 Let me draw a parallel example:

 int x;
 const alias x y;  // I want y to be a const view of x

 Does this make any sense?
Just because one particular attribute doesn't make sence doesn't mean they all don't make sence.
Jul 26 2010
parent reply =?UTF-8?B?VG9tZWsgU293acWEc2tp?= <just ask.me> writes:
W dniu 26.07.2010 22:56, Nick Sabalausky pisze:
 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vggugam1eav7ka localhost.localdomain...
 On Mon, 26 Jul 2010 15:08:32 -0400, Tomek Sowinski<just ask.me>  wrote:

 Nick Sabalausky wrote:

 Sorry you had to go through that.  My post was an attempt at dry humor
 ;)

 -Steve
Heh, now I get it too. Good one :)
Now me too:) But let's stay on the path: private void foo(); public alias foo goo; We gotta do something about this WTF. Either goo should be perfectly usable or the compiler shouldn't allow visibility expanding aliases. Which'd you pick?
Serious now: Your simple example doesn't make any sense. Why wouldn't you just make foo public? If it's publicly accessible through an alias, it's publicly accessible. I don't buy the "too hard to understand" argument. Just don't document the "private" members :) IMO, protection attributes applied to an alias make no sense whatsoever. I don't think the above code should compile, except dmd accepts lots of noop attributes...
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.
Yes, or a real-life example (sorry for quoting myself, but seems Steven's joke overshadowed it :) ): struct PermutationMatrixExpr(Permutation permut) { static if (permut == Permutation.RowWise) { alias byPermutationDim byRows; alias byPermutationOrthoDim byColumns; } else { alias byPermutationDim byColumns; alias byPermutationOrthoDim byRows; } private: // Definitions for byPermutationDim & byPermutationOrthoDim }
 Let me draw a parallel example:

 int x;
 const alias x y;  // I want y to be a const view of x

 Does this make any sense?
Just because one particular attribute doesn't make sence doesn't mean they all don't make sence.
Amen. Can anyone give a good counter-example when a public alias of a non-public symbol is evil? Tomek
Jul 26 2010
next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Tomek Sowiński wrote:

 Can anyone give a good counter-example when a public alias of a
 non-public symbol is evil?
I thought of two myself:) 1. Should class invariants be called for a public alias of a private method? 2. From D page: "A class can be exported, which means its name and all its non-private members are exposed externally to the DLL or EXE." - so a non- private alias of a private member gets exposed or not? I think there'd be a similar issue for D interface/header files. Tomek
Jul 26 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 26 Jul 2010 17:42:53 -0400, Tomek Sowiński <just ask.me> wrote:

 W dniu 26.07.2010 22:56, Nick Sabalausky pisze:
 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 Your simple example doesn't make any sense.  Why wouldn't you just make
 foo public?  If it's publicly accessible through an alias, it's  
 publicly
 accessible.  I don't buy the "too hard to understand" argument.  Just
 don't document the "private" members :)

 IMO, protection attributes applied to an alias make no sense  
 whatsoever.
 I don't think the above code should compile, except dmd accepts lots of
 noop attributes...
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.
 Yes, or a real-life example (sorry for quoting myself, but seems  
 Steven's joke overshadowed it :) ):

 struct PermutationMatrixExpr(Permutation permut) {
      static if (permut == Permutation.RowWise) {
          alias byPermutationDim byRows;
          alias byPermutationOrthoDim byColumns;
      } else {
          alias byPermutationDim byColumns;
          alias byPermutationOrthoDim byRows;
      }

 private:

 // Definitions for byPermutationDim & byPermutationOrthoDim

 }
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.
 Let me draw a parallel example:

 int x;
 const alias x y;  // I want y to be a const view of x

 Does this make any sense?
Just because one particular attribute doesn't make sence doesn't mean they all don't make sence.
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.
 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? -Steve
Jul 26 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vgg66qezeav7ka localhost.localdomain...
 On Mon, 26 Jul 2010 17:42:53 -0400, Tomek Sowinski <just 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.
Jul 26 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 27 Jul 2010 01:01:44 -0400, Nick Sabalausky <a a.a> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vgg66qezeav7ka localhost.localdomain...
 On Mon, 26 Jul 2010 17:42:53 -0400, Tomek Sowinski <just 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
Jul 27 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vgh50ulqeav7ka 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.
Jul 27 2010
prev sibling parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Steven Schveighoffer wrote:

 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.
private alias ClassFromModuleBeyondReach.awkwardStaticName awkwardHelper; Aliases *less* visible than the aliased symbol are useful and pose no trouble. Tomek
Jul 27 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 27 Jul 2010 14:42:12 -0400, Tomek Sowiński <just ask.me> wrote:

 Steven Schveighoffer wrote:

 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.
private alias ClassFromModuleBeyondReach.awkwardStaticName awkwardHelper;
This is a good point. But we are talking about aliasing a private function into a public one. Which means both must be defined in the same module. Which means the symbol being aliased is not beyond reach, and is probably pretty easy to call. But let's expand on this. Let's assume I have: private void funcA() {} public alias funcA funcB; How is this different than: public void funcB() {} private alias funcB funcA; It doesn't lend itself well to your example of byColumn and byRows, because you want to define the private function. The problem really comes down to the fact that you can't make a static decision for the name of the function, because then you have to repeat the whole function. But I'm not sure how easy it would be to implement. I also note from some experimentation that aliasing member variables doesn't work? That should probably be fixed. The "issue" of having a private function have to be declared public is not a huge one though. I don't see this being convincing enough to Walter, but maybe he would consider it. It's definitely worth putting into bugzilla. -Steve
Jul 27 2010
parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Steven Schveighoffer wrote:

 On Tue, 27 Jul 2010 14:42:12 -0400, Tomek Sowiński <just ask.me> wrote:
 
 Steven Schveighoffer wrote:

 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.
private alias ClassFromModuleBeyondReach.awkwardStaticName awkwardHelper;
This is a good point. But we are talking about aliasing a private function into a public one.
You said "private alias to a public function", look above ;)
 Which means both must be defined in the same
 module.  Which means the symbol being aliased is not beyond reach, and is
 probably pretty easy to call.
 
 But let's expand on this.  Let's assume I have:
 
 private void funcA() {}
 public alias funcA funcB;
Now import funcB from another module. It fails. If such an alias is wrong (not completely sure) then the compiler should flag it already where it's declared.
 How is this different than:
 
 public void funcB() {}
 private alias funcB funcA;
Because this always works (can use the alias) and the above doesn't.
 It doesn't lend itself well to your example of byColumn and byRows,
 because you want to define the private function.  The problem really comes
 down to the fact that you can't make a static decision for the name of the
 function, because then you have to repeat the whole function.
 
 But I'm not sure how easy it would be to implement.  I also note from some
 experimentation that aliasing member variables doesn't work?  That should
 probably be fixed.
 
 The "issue" of having a private function have to be declared public is not
 a huge one though.  I don't see this being convincing enough to Walter,
 but maybe he would consider it.  It's definitely worth putting into
 bugzilla.
Yeah, but what? That visibility expanding aliases should be useable or that the compiler should ban such declarations? I'm veering towards banning because of alias-presence-may-alter-generated-code issue I mentioned in the other post. Tomek
Jul 27 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 27 Jul 2010 17:16:57 -0400, Tomek Sowiński <just ask.me> wrote:

 Steven Schveighoffer wrote:

 On Tue, 27 Jul 2010 14:42:12 -0400, Tomek Sowiński <just ask.me> wrote:

 Steven Schveighoffer wrote:

 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.
private alias ClassFromModuleBeyondReach.awkwardStaticName awkwardHelper;
This is a good point. But we are talking about aliasing a private function into a public one.
You said "private alias to a public function", look above ;)
I know, I should have said private alias to a public function in the same module. -Steve
Jul 29 2010
prev sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Steven Schveighoffer wrote:

 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.
Of course I see it. I wouldn't ask if I didn't ;) If it doesn't make sense, the compiler should help by e.g. failing with "can't declare an alias more visible than the aliased symbol".
 Yes, or a real-life example (sorry for quoting myself, but seems
 Steven's joke overshadowed it :) ):

 struct PermutationMatrixExpr(Permutation permut) {
      static if (permut == Permutation.RowWise) {
          alias byPermutationDim byRows;
          alias byPermutationOrthoDim byColumns;
      } else {
          alias byPermutationDim byColumns;
          alias byPermutationOrthoDim byRows;
      }

 private:

 // Definitions for byPermutationDim & byPermutationOrthoDim

 }
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.
byColumns and byRows *are* public (default for structs). But it won't work now because byPermutation(Ortho)Dim are private.
 Just because one particular attribute doesn't make sence doesn't mean
 they
 all don't make sence.
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.
Again, if it's no good, ban it to make things clear.
 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?
Nick answered that. What worries me more is whether bar() should trigger the class invariant, whether bar should be exposed to exe/dll, etc. If so, this would mean the very presence of an alias can alter the code generation, which seems against alias'es spirit of being just a shortcut to a symbol. My opinion is shifting towards banning public->private aliases because of this... Tomek
Jul 27 2010
prev sibling next sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
On 25/07/10 23:23, Tomek Sowiński wrote:
 If foo is private but its public alias poo exists, should you be able to use
 poo? (currently you can't)
Visibility is a property of each symbol, not the object behind it. I see nothing wrong with allowing aliases as a way to offer public access to objects that were originally only accessible via private symbols. Imagine a public wrapper function that does nothing but call another private function. This would be conceptually very similar to a public alias of a private symbol. Nothing wrong with it.
Jul 26 2010
prev sibling parent reply Pelle <pelle.mansson gmail.com> writes:
On 07/26/2010 12:23 AM, Tomek Sowiński wrote:
 If foo is private but its public alias poo exists, should you be able to use
 poo? (currently you can't)


 Tomek
I think you should, because of this: private import package; alias package.function myFun; If you want to provide a function from a package but not forward the visibility of the entire package.
Jul 27 2010
parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Pelle wrote:

 On 07/26/2010 12:23 AM, Tomek Sowiński wrote:
 If foo is private but its public alias poo exists, should you be able to
 use poo? (currently you can't)


 Tomek
I think you should, because of this: private import package; alias package.function myFun; If you want to provide a function from a package but not forward the visibility of the entire package.
Not exactly what I had in mind. function in package must be declared as public to be able to import it so the alias is not expanding its visibility. See other posts for relevant examples. Tomek p.s. (if you already knew, ignore it) package is a keyword, so is function, and in D you import modules (files) not packages (folders).
Jul 27 2010
parent Pelle <pelle.mansson gmail.com> writes:
On 07/27/2010 08:30 PM, Tomek Sowiński wrote:
 Pelle wrote:

 On 07/26/2010 12:23 AM, Tomek Sowiński wrote:
 If foo is private but its public alias poo exists, should you be able to
 use poo? (currently you can't)


 Tomek
I think you should, because of this: private import package; alias package.function myFun; If you want to provide a function from a package but not forward the visibility of the entire package.
Not exactly what I had in mind. function in package must be declared as public to be able to import it so the alias is not expanding its visibility. See other posts for relevant examples.
But if I do a private import, I do not extend the visibility of that package beyond my current file. I want to extend the visibility of just one of the imported functions. Like this, for example: In file a: private import std.stdio; public alias std.stdio.writeln print; In file b: import a; print("Hello!"); .. Heh. This seems to work already. I probably should have tried before I posted :) I see no reason not to extend this to class level, though.
Jul 27 2010