In article <dkonud$srl$1@digitaldaemon.com>, Garett Bass says...
>
>> With DMD 0.137, when I declare a function inside a private block, it remains private for other modules, at least for my code.
>
>Tom,
>
>It gets interesting here...
>
>------------
>
>module test; // test.d
>
>private void foo() { writefln("private test.foo()"); }
>
>------------
>
>module main; // main.d
>import test;
>
>int main(char[][] args) {
>    //foo();    // Error: "module main test.foo is private"
>    test.foo(); // OK, prints: "private test.foo()"
>    return 0;
>}
>
>------------
>
>Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.

It's surely a bug, thanks for posting the code, i can see your point now.
foo() gets accessible no matter its private declaration, but only when called
specifying the enclosing module.
Now, is the private class (still visible) a bug or just undefined behavior?
If its undef. behavior, it sucks (IMHO)

Regards

Tom

In article <dkor1o$1064$1@digitaldaemon.com>, Tomás Rossi says...
>
>In article <dkonud$srl$1@digitaldaemon.com>, Garett Bass says...
>>
>>> With DMD 0.137, when I declare a function inside a private block, it remains private for other modules, at least for my code.
>>
>>Tom,
>>
>>It gets interesting here...
>>
>>------------
>>
>>module test; // test.d
>>
>>private void foo() { writefln("private test.foo()"); }
>>
>>------------
>>
>>module main; // main.d
>>import test;
>>
>>int main(char[][] args) {
>>    //foo();    // Error: "module main test.foo is private"
>>    test.foo(); // OK, prints: "private test.foo()"
>>    return 0;
>>}
>>
>>------------
>>
>>Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.
>
>It's surely a bug, thanks for posting the code, i can see your point now.
>foo() gets accessible no matter its private declaration, but only when called
>specifying the enclosing module.
>Now, is the private class (still visible) a bug or just undefined behavior?
>If its undef. behavior, it sucks (IMHO)
>

I think it is undef. because I've never seen it mentioned in the docs.

>Regards
>
>Tom

But doesn't it seem reasonable to assume that anything (methods, variables, classes, structs, templates, whatever else) declared private at module scope should be private if anything is?  Anything less would be uncivilized!

;)

"Dave" <Dave_member@pathlink.com> wrote in message news:dkp55h$1758$1@digitaldaemon.com...
> In article <dkor1o$1064$1@digitaldaemon.com>, Tomás Rossi says...
>>
>>In article <dkonud$srl$1@digitaldaemon.com>, Garett Bass says...
>>>
>>>> With DMD 0.137, when I declare a function inside a private block, it remains private for other modules, at least for my code.
>>>
>>>Tom,
>>>
>>>It gets interesting here...
>>>
>>>------------
>>>
>>>module test; // test.d
>>>
>>>private void foo() { writefln("private test.foo()"); }
>>>
>>>------------
>>>
>>>module main; // main.d
>>>import test;
>>>
>>>int main(char[][] args) {
>>>    //foo();    // Error: "module main test.foo is private"
>>>    test.foo(); // OK, prints: "private test.foo()"
>>>    return 0;
>>>}
>>>
>>>------------
>>>
>>>Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.
>>
>>It's surely a bug, thanks for posting the code, i can see your point now.
>>foo() gets accessible no matter its private declaration, but only when called
>>specifying the enclosing module.
>>Now, is the private class (still visible) a bug or just undefined behavior?
>>If its undef. behavior, it sucks (IMHO)
>>
>
> I think it is undef. because I've never seen it mentioned in the docs.
>
>>Regards
>>
>>Tom
>
> 

In article <dkp55h$1758$1@digitaldaemon.com>, Dave says...
>
>In article <dkor1o$1064$1@digitaldaemon.com>, Tomás Rossi says...
>>
>>In article <dkonud$srl$1@digitaldaemon.com>, Garett Bass says...
>>>
>>>> With DMD 0.137, when I declare a function inside a private block, it remains private for other modules, at least for my code.
>>>
>>>Tom,
>>>
>>>It gets interesting here...
>>>
>>>------------
>>>
>>>module test; // test.d
>>>
>>>private void foo() { writefln("private test.foo()"); }
>>>
>>>------------
>>>
>>>module main; // main.d
>>>import test;
>>>
>>>int main(char[][] args) {
>>>    //foo();    // Error: "module main test.foo is private"
>>>    test.foo(); // OK, prints: "private test.foo()"
>>>    return 0;
>>>}
>>>
>>>------------
>>>
>>>Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.
>>
>>It's surely a bug, thanks for posting the code, i can see your point now.
>>foo() gets accessible no matter its private declaration, but only when called
>>specifying the enclosing module.
>>Now, is the private class (still visible) a bug or just undefined behavior?
>>If its undef. behavior, it sucks (IMHO)
>>
>
>I think it is undef. because I've never seen it mentioned in the docs.

Maybe, though the docs lacks of specificity:

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

PRIVATE MODULE MEMBERS ARE EQUIVALENT TO STATIC DECLARATIONS IC C PROGRAMS. This is al little confusing to me. As Garett said, it's natural to think that "private class" would be private to other modules and it doesn't sounds like hard work to implement.

>
>>Regards
>>
>>Tom
>
>

Tom

Garett Bass wrote:
>>With DMD 0.137, when I declare a function inside a private block, it remains
>>private for other modules, at least for my code.
> 
> 
> Tom,
> 
> It gets interesting here...
> 
> ------------
> 
> module test; // test.d
> 
> private void foo() { writefln("private test.foo()"); }
> 
> ------------
> 
> module main; // main.d
> import test;
> 
> int main(char[][] args) {
>     //foo();    // Error: "module main test.foo is private"
>     test.foo(); // OK, prints: "private test.foo()"
>     return 0;
> }
> 
> ------------
> 
> Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.

I think it's wrong. I have a feeling this has very much to do with the problems I've previously had with private imports not being all that private. Now, if only Walter could to a look at this ;)

In article <dkq9h0$29gr$1@digitaldaemon.com>, Tomás Rossi says...
>
>In article <dkp55h$1758$1@digitaldaemon.com>, Dave says...
>>
>>In article <dkor1o$1064$1@digitaldaemon.com>, Tomás Rossi says...
>>>
>>>In article <dkonud$srl$1@digitaldaemon.com>, Garett Bass says...
>>>>
>>>>> With DMD 0.137, when I declare a function inside a private block, it remains private for other modules, at least for my code.
>>>>
>>>>Tom,
>>>>
>>>>It gets interesting here...
>>>>
>>>>------------
>>>>
>>>>module test; // test.d
>>>>
>>>>private void foo() { writefln("private test.foo()"); }
>>>>
>>>>------------
>>>>
>>>>module main; // main.d
>>>>import test;
>>>>
>>>>int main(char[][] args) {
>>>>    //foo();    // Error: "module main test.foo is private"
>>>>    test.foo(); // OK, prints: "private test.foo()"
>>>>    return 0;
>>>>}
>>>>
>>>>------------
>>>>
>>>>Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.
>>>
>>>It's surely a bug, thanks for posting the code, i can see your point now.
>>>foo() gets accessible no matter its private declaration, but only when called
>>>specifying the enclosing module.
>>>Now, is the private class (still visible) a bug or just undefined behavior?
>>>If its undef. behavior, it sucks (IMHO)
>>>
>>
>>I think it is undef. because I've never seen it mentioned in the docs.
>
>Maybe, though the docs lacks of specificity:
>
>"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."
>
>PRIVATE MODULE MEMBERS ARE EQUIVALENT TO STATIC DECLARATIONS IC C PROGRAMS. This is al little confusing to me. As Garett said, it's natural to think that "private class" would be private to other modules and it doesn't sounds like hard work to implement.
>

I'm not disagreeing; it is confusing and should be cleared up either in the docs., with a compiler error or by supporting private class definitions; i.e.: so they are not 'visibile' outside of a module.

I think some of the confusion (including my own on occasion) may be because it's easy to overlook the difference between 'definition' and 'declaration' - A definition is not really a 'member' of anything, a declaration is.

So, it doesn't neccessarily hold for me that

private class MyClass { ... }

and

private MyClass c;

should act the same just because of the 'private' attribute, but I wouldn't be opposed to it either.

>>
>>>Regards
>>>
>>>Tom
>>
>>
>
>Tom

In article <dkqnr5$2tut$1@digitaldaemon.com>, =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
>
>Garett Bass wrote:
>>>With DMD 0.137, when I declare a function inside a private block, it remains private for other modules, at least for my code.
>> 
>> 
>> Tom,
>> 
>> It gets interesting here...
>> 
>> ------------
>> 
>> module test; // test.d
>> 
>> private void foo() { writefln("private test.foo()"); }
>> 
>> ------------
>> 
>> module main; // main.d
>> import test;
>> 
>> int main(char[][] args) {
>>     //foo();    // Error: "module main test.foo is private"
>>     test.foo(); // OK, prints: "private test.foo()"
>>     return 0;
>> }
>> 
>> ------------
>> 
>> Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.
>
>I think it's wrong. I have a feeling this has very much to do with the problems I've previously had with private imports not being all that private. Now, if only Walter could to a look at this ;)

I do too:

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

Looks like a compiler bug to me...

Garret, do you want to post to bugs, or should I?

- Dave

In article <dkqocs$2ulq$1@digitaldaemon.com>, Dave says...
>
>In article <dkq9h0$29gr$1@digitaldaemon.com>, Tomás Rossi says...
>>
>>In article <dkp55h$1758$1@digitaldaemon.com>, Dave says...
>>>
>>>In article <dkor1o$1064$1@digitaldaemon.com>, Tomás Rossi says...
>>>>
>>>>In article <dkonud$srl$1@digitaldaemon.com>, Garett Bass says...
>>>>>
>>>>>> With DMD 0.137, when I declare a function inside a private block, it remains private for other modules, at least for my code.
>>>>>
>>>>>Tom,
>>>>>
>>>>>It gets interesting here...
>>>>>
>>>>>------------
>>>>>
>>>>>module test; // test.d
>>>>>
>>>>>private void foo() { writefln("private test.foo()"); }
>>>>>
>>>>>------------
>>>>>
>>>>>module main; // main.d
>>>>>import test;
>>>>>
>>>>>int main(char[][] args) {
>>>>>    //foo();    // Error: "module main test.foo is private"
>>>>>    test.foo(); // OK, prints: "private test.foo()"
>>>>>    return 0;
>>>>>}
>>>>>
>>>>>------------
>>>>>
>>>>>Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.
>>>>
>>>>It's surely a bug, thanks for posting the code, i can see your point now.
>>>>foo() gets accessible no matter its private declaration, but only when called
>>>>specifying the enclosing module.
>>>>Now, is the private class (still visible) a bug or just undefined behavior?
>>>>If its undef. behavior, it sucks (IMHO)
>>>>
>>>
>>>I think it is undef. because I've never seen it mentioned in the docs.
>>
>>Maybe, though the docs lacks of specificity:
>>
>>"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."
>>
>>PRIVATE MODULE MEMBERS ARE EQUIVALENT TO STATIC DECLARATIONS IC C PROGRAMS. This is al little confusing to me. As Garett said, it's natural to think that "private class" would be private to other modules and it doesn't sounds like hard work to implement.
>>
>
>I'm not disagreeing; it is confusing and should be cleared up either in the docs., with a compiler error or by supporting private class definitions; i.e.: so they are not 'visibile' outside of a module.
>
>I think some of the confusion (including my own on occasion) may be because it's easy to overlook the difference between 'definition' and 'declaration' - A definition is not really a 'member' of anything, a declaration is.

Ok, you're maybe right about that difference but D modules cause very much of
that confussion because of its nice scope rules (and it's object-like layout).
Besides that, what about this (C++)?:

class SomeObj
{
private:
int a;
typedef int Integer;

public:
SomeObj() {}
~SomeObj() {}

void some_method() { some_function(a); }
};

Is "Integer" not a definition and a private one also (we could say a private
member definition)?

>So, it doesn't neccessarily hold for me that
>
>private class MyClass { ... }
>
>and
>
>private MyClass c;
>
>should act the same just because of the 'private' attribute, but I wouldn't be opposed to it either.
>
>>>
>>>>Regards
>>>>
>>>>Tom
>>>
>>>
>>
>>Tom
>
>

Tom

Dave wrote:
> In article <dkqnr5$2tut$1@digitaldaemon.com>,
> =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
> 
>>Garett Bass wrote:
>>
>>>>With DMD 0.137, when I declare a function inside a private block, it remains
>>>>private for other modules, at least for my code.
>>>
>>>
>>>Tom,
>>>
>>>It gets interesting here...
>>>
>>>------------
>>>
>>>module test; // test.d
>>>
>>>private void foo() { writefln("private test.foo()"); }
>>>
>>>------------
>>>
>>>module main; // main.d
>>>import test;
>>>
>>>int main(char[][] args) {
>>>    //foo();    // Error: "module main test.foo is private"
>>>    test.foo(); // OK, prints: "private test.foo()"
>>>    return 0;
>>>}
>>>
>>>------------
>>>
>>>Do you think this is the intended behavior?  I'm not sure that it is wrong, but I do find it surprising.
>>
>>I think it's wrong. I have a feeling this has very much to do with the problems I've previously had with private imports not being all that private. Now, if only Walter could to a look at this ;)
> 
> 
> I do too:
> 
> "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."
> 
> Looks like a compiler bug to me...

Here is a yet another simple test case:

====>test.cpp:

#include <stdio.h>

class m { private: static const int a = 5; };

int main() {
  printf("%d", m::a);
  return 0;
}

====>test.java:

class m { private static int a = 5; }

public class m2 {
  public static void main(String[] p) {
    System.out.println(m.a);
  }
}

====>test.d:

class m { private static int a = 5; }

void main() {
  printf("%d",m.a);
}

---

test.cpp and test.java won't compile. They complain about the private keyword. test.d compiles nicely even with class m being a private class in a separate module, which shows that dmd is broken.

> Garret, do you want to post to bugs, or should I?
>
> - Dave

Dave,

I posted this issue to digitalmars.D.bugs last night.

Regards,
Garett