On Wed, 9 Nov 2005 21:50:19 +0000 (UTC), Tomás Rossi <Tomás_member@pathlink.com> wrote:
> In article <opszzrvyj923k2f5@nrage.netwin.co.nz>, Regan Heath says...
>> The current D way offers no less control than "friend" in C++ but it
>> offers it in a different way, instead of adding friend to a class you
>> place it in the same module.
>
> What about if you have no access to the module source where lies the class to
> which you want your class to be friend with? (I know, my english sucks).

It's pretty good, that sentence is going to be confusing no matter how you say it.

> The
> friend approach gives you the advantage that you do not have to modify the
> source file of the class to which you want YOUR class to be friend (that could
> be a class not written by you or you may even just not have the source, maybe
> just the .obj or .lib (is this not possible?)).
> Correct me if i'm wrong please.

I admin I am no C++ nor "friend" expert, it was my understanding that friend operates like so:

class A {
  private static int a;
  friend class B;
};

class B {
  void foo() { a = 5; }
};

class A specifies the friend who is allowed to access the private int 'a' and modify it. Without access to class A you cannot become a friend and access it's private members.

Regan

In article <inotc4h6h02k$.16dk251xzdhwx.dlg@40tude.net>, Derek Parnell says...
>
>On Thu, 10 Nov 2005 10:13:00 +1300, Regan Heath wrote:
>
>> On Wed, 9 Nov 2005 16:41:55 +1100, Derek Parnell <derek@psych.ward> wrote:
>>> 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.
>> 
>> I think to make changes you first have to remove the "constantly in effect" module-friend-public access which is applied, this effect modifies all the existing protection attributes, making them all "public" for code in the same module.
>> 
>> Once removed "private", "protected", and of course "public" would have the same meaning as in C++. Then, you could add "module" which would be "private" for code exterior to this module and "public" for code within the module. This would be the least confusing for a C++ developer coming to D I believe.
>> 
>> But, the problem with this idea is that it isn't flexible enough. Say you have a class:
>> 
>> class Foo
>> {
>>    private int a;
>>    protected int b;
>>    public int c;
>> }
>> 
>> and you need access to 'b' in this module? you can't use "module" as that makes it "private" outside the module, not "protected". So, the next logical step is to make "module" a modifier for the other 3 protection attributes.
>> 
>> That eventuality is worse than the C++ "friend" situation I feel, it does give more fine grained control but it's more verbose and fiddly as a result. In comparison the current D way is less fine grained but also much easier to use.
>
>Huh? You seem to be trying to complicate this to make it look silly. I disagree that one needs to do all the twisting and mashing of keywords and concepts you just described.
>
>Simply leave everything as it is now, and add a "local" attribute to designate those members whose scope is only the enclosing class/struct. That's it! You then get all the benefits of current D philosophy plus the added concept of reduced bonding amongst class in the same module.

I agree, but i think i understood what Regan was trying to explain. Suppose you have something like this:

--------------------------------------------------------------
module some_module;

class A { protected char[] name="class A"; } // Base class.
class B : A { public this() { name="class B"; } // Derived.
class C : A { public this() { name="class C"; } // Derived.

// Don't wanna let X gain access to protected member 'name' nor to any
// other member of A, B or C that is not public, etc.
class X { ... bla bla bla ... }
--------------------------------------------------------------

Clearly, if you want to let 'B' and 'C' gain access to 'name', you cannot declare it 'local' you'll have rather declare it 'protected'. But this will leave it visible to the other classes of the module.

And what i understood from what Regan said:

--------------------------------------------------------------
module some_module;

class A { local protected char[] name="class A"; } // Base class.
class B : A { public this() { name="class B"; } // Derived.
class C : A { public this() { name="class C"; } // Derived.

// X will not have access to 'A.name', 'B.name' or 'C.name'. class X { ... bla bla bla ... }
--------------------------------------------------------------

>Using this "local" concept, it still allows two classes in the same module to have access to "private" members but not access to "local" members.
>
>> The current D way offers no less control than "friend" in C++ but it offers it in a different way, instead of adding friend to a class you place it in the same module.
>
>Yes, exactly. And that is the problem. It forces one to place 'friend' classes into the same module, but by doing that one also increases the cost of maintenance by implicitly increasing the binding between such classes.
>
>> Does Java have anything for the same purpose? perhaps inner classes? I'm no Java expert and I'm curious.
>
>Maybe inner classes are the solution. I don't know as I haven't really explored this yet.
>
>-- 
>Derek Parnell
>Melbourne, Australia
>10/11/2005 8:46:17 AM

Tom

On Thu, 10 Nov 2005 01:49:14 +0200, Jari-Matti Mäkelä <jmjmak@invalid_utu.fi> wrote:
> (sorry, had to answer twice - this message was a bit confusing :)
>
> Regan Heath wrote:
>> On Wed, 9 Nov 2005 16:41:55 +1100, Derek Parnell <derek@psych.ward> wrote:
>>
>>> 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.
> I disagree. Private is a standard keyword in many oo-languages. You don't need these "local"-members anywhere. The idea behind "friends" and D modules is not that you'll put all your classes in the same module. If the classes are somehow internally related, you can have them in the same module, otherwise keep them in separate modules. That way there's no need the make things more complex than they really are.

I agree.

>>> 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.
>>   That's cos it was a workaround ;)
>
> No, that's not a workaround. The private constructor exists because that way you can't instantiate a class outside the class body. It has nothing to do with visibility keywords on the module level.

My mistake, I agree.

>> It would be nice to be able to hide a class with a single keyword in the  logical place. It seems that place is on the class definition, I agree.
>
>  From http://www.digitalmars.com/d/attribute.html:
>
> "Static does not have the additional C meaning of being local to a file. Use the private attribute in D to achieve that. For example:
>    module foo;
>    int x = 3;		// x is global
>    private int y = 4;	// y is local to module foo
>
> Now the D specification has the functionality you need, but the implementation doesn't care about private-keyword. I hope that's the bug we are all hunting down here, right?

I beliece that currently the 'private' keyword is only applied to instances of things i.e. an int or a class reference. It's not being applied to declarations i.e. enum, class, struct, alias, typdef etc.

So, does the spec say it should? (is it a bug?)
Do we think it should? (is it a new feature to be added?)

Regan

On Thu, 10 Nov 2005 01:33:14 +0200, Jari-Matti Mäkelä <jmjmak@invalid_utu.fi> wrote:
> Regan Heath wrote:
>> Does Java have anything for the same purpose? perhaps inner classes? I'm  no Java expert and I'm curious.
>
> Java does have a similar system using packages. You can declare a top-level class as public/package (no keyword). Only one public class per package (module) is allowed, other classes must be "hidden" so that they're not polluting the namespace when the package is imported. Therefore only public classes are accessible from other modules. You need to explicitely write the "package foobar" line inside the source to use packages.
>
> You can also use inner & nested classes in Java. A nested class is a static class inside another class. You may declare nested class as private/protected/... just like any static class member. Private nested class isn't accessible outside the outer class.
>
> Inner classes are dynamic classes inside class objects that usually inherit some common interface. You may declare inner class as private/protected/... just like any class member. Declaring the inner class as private means that you only can use the inner class via Object/superclass-methods since the class declaration is hidden.
>
> I think the package system in Java is ok and the current D implementation is broken. I have an example in one of my previous posts.

Thanks.

So, does Java have something like "friend" in C++? Does a class ever gain access to another classes 'private' data? If so, how? If not, why has it never been required? (as it was in C++? debatable?)

Regan

> I admin I am no C++ nor "friend" expert, it was my understanding that friend operates like so:

TYPO: "admin" == "admit"

Regan

In article <dku1m7$2n32$1@digitaldaemon.com>, =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= says...
>
>(sorry, had to answer twice - this message was a bit confusing :)
>
>Regan Heath wrote:
>> On Wed, 9 Nov 2005 16:41:55 +1100, Derek Parnell <derek@psych.ward> wrote:
>> 
>>> 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.
>I disagree. Private is a standard keyword in many oo-languages. You don't need these "local"-members anywhere. The idea behind "friends" and D modules is not that you'll put all your classes in the same module. If the classes are somehow internally related, you can have them in the same module, otherwise keep them in separate modules. That way there's no need the make things more complex than they really are.

I dont understand? How do you achieve "friend" behavior between two classes in different modules?

>>> 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.
>> 
>> 
>> That's cos it was a workaround ;)
>
>No, that's not a workaround. The private constructor exists because that way you can't instantiate a class outside the class body. It has nothing to do with visibility keywords on the module level.
>
>> It would be nice to be able to hide a class with a single keyword in the  logical place. It seems that place is on the class definition, I agree.
>
> From http://www.digitalmars.com/d/attribute.html:
>
>"Static does not have the additional C meaning of being local to a file. Use the private attribute in D to achieve that. For example:
>   module foo;
>   int x = 3;		// x is global
>   private int y = 4;	// y is local to module foo
>
>Now the D specification has the functionality you need, but the implementation doesn't care about private-keyword. I hope that's the bug we are all hunting down here, right?

On Thu, 10 Nov 2005 00:17:44 +0000 (UTC), Tomás Rossi <Tomás_member@pathlink.com> wrote:
> I agree, but i think i understood what Regan was trying to explain.

Yes, you have.
Regan

Regan Heath wrote:
> So, does Java have something like "friend" in C++? Does a class ever gain  access to another classes 'private' data? If so, how? If not, why has it  never been required? (as it was in C++? debatable?)

Yes, all classes in the same package (Java package = D module) share their private data. This is no problem (unless you run out of inodes ;)) since all non-friendly classes can be split into separate packages.

Tomás Rossi wrote:
>>I disagree. Private is a standard keyword in many oo-languages. You don't need these "local"-members anywhere. The idea behind "friends" and D modules is not that you'll put all your classes in the same module. If the classes are somehow internally related, you can have them in the same module, otherwise keep them in separate modules. That way there's no need the make things more complex than they really are.
> 
> 
> I dont understand? How do you achieve "friend" behavior between two classes in
> different modules?
Actually I think I'm not following your train of thought. You can't have both "local"- and "friend"-functionality at the same time. Friend-relationship means that the private members are accessible, this local-visibility seems the mean that the private members are inaccessible inside the "friend" class.

On Thu, 10 Nov 2005 02:34:36 +0200, Jari-Matti Mäkelä <jmjmak@invalid_utu.fi> wrote:
> Regan Heath wrote:
>> So, does Java have something like "friend" in C++? Does a class ever gain  access to another classes 'private' data? If so, how? If not, why has it  never been required? (as it was in C++? debatable?)
>
> Yes, all classes in the same package (Java package = D module) share their private data. This is no problem (unless you run out of inodes ;)) since all non-friendly classes can be split into separate packages.

Ahh, so that works like it does in D... only D calls them modules to Java's packages and D have another thing called a "package" and a protection attribute for that too.

Thanks.

Regan