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