www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - "private" and "protected" not working?!

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
two bugs in ten minutes!

private in a class does nothing.

class A
{
 private int x;
}

void main()
{
 A a=new A;
 a.x=5;
 printf("%d\n",a.x);
}

perfectly legal.

ummmmmmmmmmmm.........
Jul 12 2004
parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Jarrett Billingsley wrote:

 two bugs in ten minutes!
 
 private in a class does nothing.
 
 class A
 {
  private int x;
 }
 
 void main()
 {
  A a=new A;
  a.x=5;
  printf("%d\n",a.x);
 }
 
 perfectly legal.
 
 ummmmmmmmmmmm.........
 
 


Well, no... actually it's not a bug...  The manual states (under 
attributes):

"Private means that only members of the enclosing class can access the 
member, or members and functions in the same module as the enclosing 
class. Private members cannot be overridden. Private module members are 
equivalent to static declarations in C programs."

So the above is legal, since main is within the same module as that class.
Jul 12 2004
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
ohh.

so i suppose i would have to put the class in a separate module.  how odd.
Jul 12 2004
parent reply John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Jarrett Billingsley wrote:

 ohh.
 
 so i suppose i would have to put the class in a separate module.  how odd.
 
 


Yep... that's what I thought when I first saw that too.

Like a few other people have mentioned, thinking in D can take a bit of 
getting used to.  It also makes porting software from other languages 
like C++ and java somewhat of a pain: the apparant similarities can 
cause severe headaches if you don't understand D completely.  Yet like 
everything else, once you get used to it, it's not so weird anymore.

If ever a book is written about D, "Thinking in D" will be a very 
appropriate title for it (maybe with the subtitle: "and Saving Yourself 
a Few Headaches."

Not to malign the D language.  It's wonderful and simple for the most 
part.  It just takes some getting used to at on some levels.
Jul 12 2004
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
perhaps you can help me with this problem.  now that i've put the class in
another module and have that working.. why can't i make it private?  i can
make a private int and if i try to access it i get an error.. but a private
class is as available as any other.  i suppose it's something about private
in modules being the same behavior as static in C, but wouldn't it make more
sense if private classes.. were private to the module?
Jul 12 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Jarrett Billingsley wrote:


perhaps you can help me with this problem.  now that i've put the class in
another module and have that working.. why can't i make it private?  i can
make a private int and if i try to access it i get an error.. but a private
class is as available as any other.  i suppose it's something about private
in modules being the same behavior as static in C, but wouldn't it make more
sense if private classes.. were private to the module?


  


You can important a module as private:

private import m2;

Therefore for a private class you need yet another level of modules.  
Which is a good design thing anyway.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jul 13 2004
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 Therefore for a private class you need yet another level of modules.
 Which is a good design thing anyway.


bah :P
Jul 13 2004
prev sibling parent John Reimer <brk_6502 NO_SPA_M.yahoo.com> writes:
Jarrett Billingsley wrote:


 perhaps you can help me with this problem.  now that i've put the class in
 another module and have that working.. why can't i make it private?  i can
 make a private int and if i try to access it i get an error.. but a
 private
 class is as available as any other.  i suppose it's something about
 private in modules being the same behavior as static in C, but wouldn't it
 make more sense if private classes.. were private to the module?


You know what? I don't really know the answer to that question.  I've
investigated it also and what you say is correct.  The private attribute
doesn't appear to be honored the same way at the module level as you would
expect from a class.  Some extra investigation showed that not even a
"private int" is really private to the module if you access it with a fully
qualified name in another module.  Here's an example:

=====================================
// testmod.d
module testmod;

private {
        int x;
        class TestClass { int x; }
        struct TestStruct { int x; }
}
=====================================
//  test.d
module test;

import std.stdio;
import testmod;

int main() {
        TestClass A = new TestClass; // private TestClass accessible
        A.x = 1;
        TestStruct B;   // private TestStruct accessible 
        B.x =2;
        testmod.x = 3;  // private int x accessible only if fully qualified
                
        writefln(A.x);
        writefln(B.x);
        writefln(testmod.x);
        return 0;
}
=====================================

All private symbols in testmod are accessible from test.  testmod.x is only
accessible if it is fully qualified, otherwise the compile stops with the
error you mentioned above (private access isn't allowed). The same rule is
not necessary for using TestClass and TestStruct, ie fully qualifying
them).  I can't really explain the reasoning for that other than that x is
an actual variable and TestClass & TestStruct are not (so access
permissions to them are different? I don't really understand why it works
that way).  Given the private attribute in testmod, I don't really see how
any of them can be legally accessible unless...

From what I see, a module works differently from a class or struct. 
Importing a module into another module appears to make all symbols, public
or private (at the module level) accessible as if they were directly
inserted into the new module (I guess this makes sense to some degree;
module's and classes really are different beasts).  It looks like "import"
almost acts like a sort of mixin.  So the private attribute on the module
level appears to be meaningless once an import pulls it into the other
module. I don't know how much sense this make.  I think some details from
some d experts would be useful about now.

Sorry that I can't help you more on this one.  Good food for thought,
though.

Later,

John
Jul 13 2004