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.........

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.

ohh.

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

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.

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?

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/

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

bah :P

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