In article <dkr5fu$msq$1@digitaldaemon.com>, Garett Bass says...
>
>> 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

Why cant i see the post? The last bug that appears is Oct 03 2005    Ddoc BODY macro

A little out of date...
The URL is http://www.digitalmars.com/d/archives/digitalmars/D/bugs/
Am i right?


Tom

In article <dkrdcq$19tq$1@digitaldaemon.com>, Tomás Rossi says...
>
>In article <dkr5fu$msq$1@digitaldaemon.com>, Garett Bass says...
>>
>>> 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
>
>Why cant i see the post? The last bug that appears is Oct 03 2005    Ddoc BODY macro
>
>A little out of date...
>The URL is http://www.digitalmars.com/d/archives/digitalmars/D/bugs/
>Am i right?

Oh, i guess this was the one http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs Sorry, it was a lapsus! (i'm a little new here)

Tom

In article <dkr12p$buk$1@digitaldaemon.com>, =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
>
>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);
>}

Ok, Regan showed me earlier that this (private member of a class in the same
module) is accessible from anyplace in the enclosing module, so it's not a bug.
(http://www.digitalmars.com/d/attribute.html)

I personally think that this behavior is useless and confusing.

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

Regards

Tom

On Wed, 9 Nov 2005 03:43:17 +0000 (UTC), Tomás Rossi wrote:


[snip]
> Ok, Regan showed me earlier that this (private member of a class in the same
> module) is accessible from anyplace in the enclosing module, so it's not a bug.
> (http://www.digitalmars.com/d/attribute.html)
> 
> I personally think that this behavior is useless and confusing.

As near as I can figure it out, in D:-

** "private" means private to the module (source file), and not anything smaller. It can only be applied to class members and module members.

** "protected" is identical to "private" except for two differences. It can only be applied to class members, and it extends access to classes derived from a class that contains "protected" members.

** "package" means private to the package (source files in the same folder), and not anything smaller. It can only be applied to class members and module members.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/11/2005 2:50:20 PM

On Wed, 9 Nov 2005 03:43:17 +0000 (UTC), Tomás Rossi <Tomás_member@pathlink.com> wrote:
>> ====>test.d:
>>
>> class m { private static int a = 5; }
>>
>> void main() {
>>   printf("%d",m.a);
>> }
>
> Ok, Regan showed me earlier that this (private member of a class in the same module) is accessible from anyplace in the enclosing module, so it's not a bug. (http://www.digitalmars.com/d/attribute.html)
>
> I personally think that this behavior is useless and confusing.

Think of it as a replacement for the "friend" system in C++.

"friend" in C++ is an example of a solution to the need to obtain access to a part of a class that is normally off limits to external methods. Technically (I believe) it's a violation of strict OO principles.

Does Java have a similar mechanism? Does the need never arise in Java?

In order to get into the way D does it you have to adjust your perspective such that the "module" is the encapsulating entity, as opposed to the class.

A module in D encapsulates an idea/concept/tool and exposes an interface which other modules can then import and use. It can expose several classes, classes which can be tightly bound together if that is what is required.

I prefer it to the C++ "friend" system.

Regan

In article <opszygscna23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Wed, 9 Nov 2005 03:43:17 +0000 (UTC), Tomás Rossi <Tomás_member@pathlink.com> wrote:
>>> ====>test.d:
>>>
>>> class m { private static int a = 5; }
>>>
>>> void main() {
>>>   printf("%d",m.a);
>>> }
>>
>> Ok, Regan showed me earlier that this (private member of a class in the same module) is accessible from anyplace in the enclosing module, so it's not a bug. (http://www.digitalmars.com/d/attribute.html)
>>
>> I personally think that this behavior is useless and confusing.
>
>Think of it as a replacement for the "friend" system in C++.
>
>"friend" in C++ is an example of a solution to the need to obtain access to a part of a class that is normally off limits to external methods. Technically (I believe) it's a violation of strict OO principles.
>
>Does Java have a similar mechanism? Does the need never arise in Java?
>
>In order to get into the way D does it you have to adjust your perspective such that the "module" is the encapsulating entity, as opposed to the class.
>
>A module in D encapsulates an idea/concept/tool and exposes an interface which other modules can then import and use. It can expose several classes, classes which can be tightly bound together if that is what is required.
>
>I prefer it to the C++ "friend" system.

What about having another attribute to allow other entities in the same module to gain access to that members? For example:

module some_module;

private class Aux
{
private:
static int invisible_outside_class = 8;
module:
static int n = 5;
static float f = 3.14;
}

public class ExportedObject
{
private float somesum = 0.0;
public this()
{
somesum = Aux.n + Aux.f; // OK.
somesum += Aux.invisible_outside_class; // ERROR, PRIVATE MEMBER ACCESS.
}
public float giveme_somesum() { return somesum; }
}

--------

module main;
import some_module;

int main()
{
int k = Aux.n; // ERROR, PRIVATE CLASS.
int j = Aux.invisible_outside_class; // ERROR, PRIVATE CLASS.

ExportedObject eo = new ExportedObject(); // OK (WITHOUT THE ERROR STATEMENT).
float r = eo.giveme_somenum(); // OK.

return 0;
}

Regards

Tom

On Wed, 9 Nov 2005 05:12:23 +0000 (UTC), Tomás Rossi wrote:

> In article <opszygscna23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>>On Wed, 9 Nov 2005 03:43:17 +0000 (UTC), Tomás Rossi <Tomás_member@pathlink.com> wrote:
>>>> ====>test.d:
>>>>
>>>> class m { private static int a = 5; }
>>>>
>>>> void main() {
>>>>   printf("%d",m.a);
>>>> }
>>>
>>> Ok, Regan showed me earlier that this (private member of a class in the same module) is accessible from anyplace in the enclosing module, so it's not a bug. (http://www.digitalmars.com/d/attribute.html)
>>>
>>> I personally think that this behavior is useless and confusing.
>>
>>Think of it as a replacement for the "friend" system in C++.
>>
>>"friend" in C++ is an example of a solution to the need to obtain access to a part of a class that is normally off limits to external methods. Technically (I believe) it's a violation of strict OO principles.
>>
>>Does Java have a similar mechanism? Does the need never arise in Java?
>>
>>In order to get into the way D does it you have to adjust your perspective such that the "module" is the encapsulating entity, as opposed to the class.
>>
>>A module in D encapsulates an idea/concept/tool and exposes an interface which other modules can then import and use. It can expose several classes, classes which can be tightly bound together if that is what is required.
>>
>>I prefer it to the C++ "friend" system.
> 
> What about having another attribute to allow other entities in the same module to gain access to that members? For example:
> 
> module some_module;
> 
> private class Aux
> {
> private:
> static int invisible_outside_class = 8;
> module:
> static int n = 5;
> static float f = 3.14;
> }
> 
> public class ExportedObject
> {
> private float somesum = 0.0;
> public this()
> {
> somesum = Aux.n + Aux.f; // OK.
> somesum += Aux.invisible_outside_class; // ERROR, PRIVATE MEMBER ACCESS.
> }
> public float giveme_somesum() { return somesum; }
> }
> 
> --------
> 
> module main;
> import some_module;
> 
> int main()
> {
> int k = Aux.n; // ERROR, PRIVATE CLASS.
> int j = Aux.invisible_outside_class; // ERROR, PRIVATE CLASS.
> 
> ExportedObject eo = new ExportedObject(); // OK (WITHOUT THE ERROR STATEMENT).
> float r = eo.giveme_somenum(); // OK.
> 
> return 0;
> }
> 
> Regards
> 
> Tom

I think I'd prefer a new protection attribute to limit scope to within a class or struct. Something like ...

 class Aux
 {
 local:
 static int invisible_outside_class = 8;
 private:
 static int n = 5;
 static float f = 3.14;
 }

And even rename "private" to "module" to make it more clear as to its scope.

A further useful protection facility would be to make a class definition invisible to other source files. Currently the use of "private" on the "class" definition is ignored but it could be used to hide a class from other modules. The current technique of designating the class constructor as private is a bit obtuse and smacks of a "workaround fix" rather than a thought out solution to the real problem.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/11/2005 4:32:07 PM

On Wed, 9 Nov 2005 05:12:23 +0000 (UTC), Tomás Rossi <Tomás_member@pathlink.com> wrote:
> In article <opszygscna23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>> On Wed, 9 Nov 2005 03:43:17 +0000 (UTC), Tomás Rossi
>> <Tomás_member@pathlink.com> wrote:
>>>> ====>test.d:
>>>>
>>>> class m { private static int a = 5; }
>>>>
>>>> void main() {
>>>>   printf("%d",m.a);
>>>> }
>>>
>>> Ok, Regan showed me earlier that this (private member of a class in the
>>> same module) is accessible from anyplace in the enclosing module, so
>>> it's not a bug. (http://www.digitalmars.com/d/attribute.html)
>>>
>>> I personally think that this behavior is useless and confusing.
>>
>> Think of it as a replacement for the "friend" system in C++.
>>
>> "friend" in C++ is an example of a solution to the need to obtain access
>> to a part of a class that is normally off limits to external methods.
>> Technically (I believe) it's a violation of strict OO principles.
>>
>> Does Java have a similar mechanism? Does the need never arise in Java?
>>
>> In order to get into the way D does it you have to adjust your perspective
>> such that the "module" is the encapsulating entity, as opposed to the
>> class.
>>
>> A module in D encapsulates an idea/concept/tool and exposes an interface
>> which other modules can then import and use. It can expose several
>> classes, classes which can be tightly bound together if that is what is
>> required.
>>
>> I prefer it to the C++ "friend" system.
>
> What about having another attribute to allow other entities in the same module
> to gain access to that members? For example:

<snip example>

You could. But why benfit does that have over the current way?

Chances are you're the author of all the code in the module, if so what's the point of restricting that code from interacting with itself to any extent it needs/wants to?

My perspective is that if you look at the D module as being comparable to a class from C++/Java (in terms of being the encapsulating entity) then take your suggestion back to C++/Java it's like saying, why not have an attribute to allow part of my class access to the another part of my class.

Now, you may or may not believe that's a valid comparrison, I reckon it depends on how you view D's modules, are they just files that contain code, or are they an encapsulating entity?

Regan

On Wed, 09 Nov 2005 18:42:24 +1300, Regan Heath wrote:


> You could. But why benfit does that have over the current way?
> 
> Chances are you're the author of all the code in the module, if so what's the point of restricting that code from interacting with itself to any extent it needs/wants to?
> 
> My perspective is that if you look at the D module as being comparable to a class from C++/Java (in terms of being the encapsulating entity) then take your suggestion back to C++/Java it's like saying, why not have an attribute to allow part of my class access to the another part of my class.

The only thing I can see as a benefit is that it reduces cohesion between classes and makes them more independent. I enhances the separation of concerns within the module.

It is a similar situation with the use of goto. Even though uses of goto
are probably written by the same author in the same file, their presence
reduces the independence of the code sections. With 'friend' members,
coders, and in particular maintenance coders, need to be aware that changes
to such members have the potential of creating side effects that are not in
the lexical vicinity of the member. In other words, currently if I change a
"private" member's data type I should also scan the other classes in the
module, and module level code, to see if my change upsets them. If that
member was designated as locally scoped to the enclosing class, my change
has less code to upset.

> Now, you may or may not believe that's a valid comparrison, I reckon it depends on how you view D's modules, are they just files that contain code, or are they an encapsulating entity?

I think that the module concept as an encapsulating entity is a neat idea too.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/11/2005 4:47:51 PM

Tomás Rossi wrote:
>>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);
>>}
> 
> 
> Ok, Regan showed me earlier that this (private member of a class in the same
> module) is accessible from anyplace in the enclosing module, so it's not a bug.
> (http://www.digitalmars.com/d/attribute.html)
> 
> I personally think that this behavior is useless and confusing.

I like the idea that all declarations are "friends" in the same module. But now _all_ top level symbols can be imported to another module. I think this an error in language design since now it's possible that all classes in separate modules become friends when "public" import is used. This has a nasty side effect:

module module1:

  class foo { int a; }

module module2:

  import module1;

module module3:

  import module1;

module module4:

import module2, module3;

foo a = new foo(); // now should we use module2.foo or module3.foo

I know this probably doesn't produce an error right now. But with bigger projects it becomes a nuisance. As a practical workaround you need to import module2 in module3 to prevent some nasty ambiguities. I'm still working on a minimal test case.

What I was saying was that D desperately needs a way to make code invisible in a separate module.
You see this also works:

====>module1.d:
module module1;
  private class foo { private static int a = 5; }

====>module2.d:
module module2;
  private import module1;

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

---

As a workaround I need to chain these modules with multiple private imports now:

module module1;

  private class foo { private static int a = 5; }

module workaround:

  private import module1;

module module3;

  import workaround;

  void main() {printf("%d", foo.a);} //now it works(ie. doesn't compile)