Tomás Rossi wrote:
>>>>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.
> 
> 
> I know and I didn't mean that.

So what's the problem then? If you want classes to be friends, put them in the _same_ module, otherwise put them in _separate_ modules.

Think of the friend classes as an extra. You can do everything you want without any friend classes. Now if you find classes that share their private members a lot, you may want to reduce the amount of pointless wrappers around private properties. Ok, now you can use private classes. So, that's it. If you just need the basic inheritance or customer relationship, there's no need to put these classes/functions in the same module, right?

>>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.
> 
> 
> Local means: THAT MEMBER (the local one), can´t be accessed by another class in
> the same module.

Therefore the local keyword means that no other class in any module can access that member either. But this visibility is already possible to achieve using separate modules.

The only "shortcoming" with modules is that you cannot have both local and private members in the same class. But I find that requirement insane since the "friend"-behaviour isn't the default access method in oo-languages - you can use encapsulation.

> Hope you catched my train of thought this time :)

I hope that too :)

In article <opsz0cvbvz23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Thu, 10 Nov 2005 04:00:38 +0000 (UTC), Tomás Rossi <Tomás_member@pathlink.com> wrote:
>> In article <opszz9bmiy23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>
>>> On Thu, 10 Nov 2005 03:11:52 +0000 (UTC), Tomás Rossi
>>> <Tomás_member@pathlink.com> wrote:
>>>> In article <opszz5jlgs23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>>>
>>>>> On Thu, 10 Nov 2005 01:48:56 +0000 (UTC), Tomás Rossi
>>>>> <Tomás_member@pathlink.com> wrote:
>>>>>> In article <opszz0bk0623k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> For an example of what I mean, take a look of iostreams << and >>
>>>>>> operator
>>>>>> overloading. That was to what i was referring to.
>>>>>
>>>>> Take a look at what? the source code? (I assume you mean C++'s
>>>>> iostreams
>>>>> << and >> operators)
>>>>
>>>> Think I was pretty obvious here.
>>>
>>> Obviously not :)
>>
>> Ok, maybe I've assumed to much of your C++ knowledge here, sorry.
>>
>>>>> I'm not that well versed in C++ (mostly a C programmer) so I haven't
>>>>> used
>>>>> these, nor do I know how they're constructed. Can you give a
>>>>> simplified
>>>>> example?
>>>
>>> <snip>
>>>
>>> I understand what you mean now, you're saying C++ has friend functions
>>> as
>>> well as friend classes. So does D, any function in the same module as a
>>> class is a "friend" function.
>>
>> Yap! :D, I think now we are in the same train of thought ;)
>> Thats what I meant. If you want to do something like this in D you just
>> can't because you're not supposed to add code to std modules (that would
>> be iostream in C++, a standard source files with standard objects the
>> user isn't supposed to touch), or to add code to someone else's modules
>> to make the friendship, that's obviously just an "YYYYAAACK, BAD BOY!"
>> thing.
>
>Hold on. The code you posted had an operator<< overload, that overload was designated as a friend of SimpleStack<T> not of iostream, it has access to the private members of SimpleStack<T> not iostream. In order to achive that you had to modify SimpleStack<T> adding this line:
>
>   friend ostream &operator<< <T> (ostream &os, const SimpleStack<T> &ss);
>
>It's no different in D, you would have to place the operator overload in the same module as the SimpleStack<T> class.

But in D you have to put BOTH OF THE TWO CLASSES in the same module. I never say you wouldn't have to modify your class. Suppose you have something like iostreams in D. And suppose they are part of Phobos. Now you want to write a SimpleStack and want to overload << operator for it to output to the screen in a SimpleStack custom way. Then just to achieve any friendship you'd have to write SimpleStack into iostream standard module (and I don't really think you can do that at all). That or I don't understand what are you trying to say.

Regards

Tom

In article <dkv77l$12b6$1@digitaldaemon.com>, =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
>
>Tomás Rossi wrote:
>>>>>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.
>> 
>> 
>> I know and I didn't mean that.
>
>So what's the problem then? If you want classes to be friends, put them in the _same_ module, otherwise put them in _separate_ modules.
>
>Think of the friend classes as an extra. You can do everything you want without any friend classes. Now if you find classes that share their private members a lot, you may want to reduce the amount of pointless wrappers around private properties. Ok, now you can use private classes. So, that's it. If you just need the basic inheritance or customer relationship, there's no need to put these classes/functions in the same module, right?
>
>>>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.
>> 
>> 
>> Local means: THAT MEMBER (the local one), can´t be accessed by another class in
>> the same module.
>
>Therefore the local keyword means that no other class in any module can access that member either. But this visibility is already possible to achieve using separate modules.
>
>The only "shortcoming" with modules is that you cannot have both local and private members in the same class. But I find that requirement insane since the "friend"-behaviour isn't the default access method in oo-languages - you can use encapsulation.

I know that from an OO point of view friendship is ugly, but as Walter said,
sometimes you have to break the rules. :)
As an example of what C++ friendship could do vs. D inside-the-same-module
approach, I mentioned C++ iostream "<< operator" overload kind of friendship.
This is by far impossible with D approach. Take a look of the previous
discussion with Regan for more details. Hope I had explained myself.

>> Hope you catched my train of thought this time :)
>
>I hope that too :)

Tom

Tomás Rossi wrote:
> 
> But in D you have to put BOTH OF THE TWO CLASSES in the same module. I never say
> you wouldn't have to modify your class. Suppose you have something like
> iostreams in D. And suppose they are part of Phobos. Now you want to write a
> SimpleStack and want to overload << operator for it to output to the screen in a
> SimpleStack custom way. Then just to achieve any friendship you'd have to write
> SimpleStack into iostream standard module (and I don't really think you can do
> that at all). That or I don't understand what are you trying to say.

You can do the same thing in D, but the way you do it is a little bit different.

class SimpleStack(T)
{
  ostream opShl_r(ostream o)
  {
     o << something;
     return o;
  }
  private something;
}

as opShl_r is defined in SimpleStack it has access to SimpleStack's private parts.

Hope this helps in this neverending discussion :)

In article <dkvjhk$1dtg$1@digitaldaemon.com>, Ivan Senji says...
>
>Tomás Rossi wrote:
>> 
>> But in D you have to put BOTH OF THE TWO CLASSES in the same module. I never say you wouldn't have to modify your class. Suppose you have something like iostreams in D. And suppose they are part of Phobos. Now you want to write a SimpleStack and want to overload << operator for it to output to the screen in a SimpleStack custom way. Then just to achieve any friendship you'd have to write SimpleStack into iostream standard module (and I don't really think you can do that at all). That or I don't understand what are you trying to say.
>
>You can do the same thing in D, but the way you do it is a little bit different.
>
>class SimpleStack(T)
>{
>   ostream opShl_r(ostream o)
>   {
>      o << something;
>      return o;
>   }
>   private something;
>}
>
>as opShl_r is defined in SimpleStack it has access to SimpleStack's private parts.
>
>Hope this helps in this neverending discussion :)

Ok, this beats specifically the << operator overloading example, but there could be another similar example that doesn't use an operator and instead use just a member function. I'll think about it and post it (if I found one).  I doubt this specific example will puff out this nice discussion :)

Tom

Tomás Rossi wrote:
> In article <dkvjhk$1dtg$1@digitaldaemon.com>, Ivan Senji says...
>>as opShl_r is defined in SimpleStack it has access to SimpleStack's private parts.
>>
>>Hope this helps in this neverending discussion :)
> 
> 
> Ok, this beats specifically the << operator overloading example, but there could
> be another similar example that doesn't use an operator and instead use just a
> member function. I'll think about it and post it (if I found one).  I doubt this
> specific example will puff out this nice discussion :)
> 
> Tom

Other than this what would be the case where you wish to grant some other (possibly library) class access to your classes private parts?
I think that one can adjust to this /limitation/ in D. I don't even think it is a limitation, in most cases i wish my classes have friendship relationship and it is easy to accomplish that (put them in the same module).

On the other topic i am starting to think that it would be nice to be able to split modules into more files. C# can now even split classes into more files but it is another discussion.

Ivan Senji wrote:
> Other than this what would be the case where you wish to grant some other (possibly library) class access to your classes private parts?
> I think that one can adjust to this /limitation/ in D. I don't even think it is a limitation, in most cases i wish my classes have friendship relationship and it is easy to accomplish that (put them in the same module).

I agree ;)

> 
> On the other topic i am starting to think that it would be nice to be able to split modules into more files. C# can now even split classes into more files but it is another discussion.

But I thought we have packages already. I'm sure it's technically easy to support distributed module files. OTOH it's also possible to support multiple modules in a single file. I've used a text editor with code folding support for almost ten years now so having long source files isn't a problem. Can you come up with a practical example perhaps?

In article <dkvsqj$1ndm$1@digitaldaemon.com>, Ivan Senji says...
>
>Tomás Rossi wrote:
>> In article <dkvjhk$1dtg$1@digitaldaemon.com>, Ivan Senji says...
>>>as opShl_r is defined in SimpleStack it has access to SimpleStack's private parts.
>>>
>>>Hope this helps in this neverending discussion :)
>> 
>> 
>> Ok, this beats specifically the << operator overloading example, but there could be another similar example that doesn't use an operator and instead use just a member function. I'll think about it and post it (if I found one).  I doubt this specific example will puff out this nice discussion :)
>> 
>> Tom
>
>Other than this what would be the case where you wish to grant some other (possibly library) class access to your classes private parts? I think that one can adjust to this /limitation/ in D. I don't even think it is a limitation, in most cases i wish my classes have friendship relationship and it is easy to accomplish that (put them in the same module).

I still think it looks very dirty to allow other classes from the same module to touch private members of each others (IMHO this could be a nice feature but not to be the default behavior, maybe it should have a keyword behind it). What about all the nice contract programming features? PRE/POST-conditions and invariants? (just asking). I feel that this permissive behavior goes one step back just after going a step forward with contract programming. If it's ugly to break the invariant of a class inside it, imagine breaking it from the outside. I sincerely distrust of the feature.

Quote: "in most cases i wish my classes have friendship relationship and it is
easy to accomplish that".
Yeah it's nice, but it'd be nicer if you could have more control of this in a
more detailed way (e.g. adding more attributes or modifiers if it is necessary).
I'm not saying this in-module-friendship is bad, just wish it to be optional to
avoid the "paradox" it is (IMO) with respect to contract programming philosophy
(not being to much of a scientist here, this is just what I perceive :) ). One
advantage of friend keyword approach (e.g. C++) is that with it, you can control
exactly WHO would you let to put their hands on the most intimate members of
your object.

>On the other topic i am starting to think that it would be nice to be able to split modules into more files. C# can now even split classes into more files but it is another discussion.

PS: stop with the "if you don't want any other entity to gain access to your class privates, put it on another module!", THE WORLD ISN'T JUST BLACK OR WHITE.

Tom

Tomás Rossi wrote:
> In article <dkvsqj$1ndm$1@digitaldaemon.com>, Ivan Senji says...
> 
>>Tomás Rossi wrote:
>>
>>>In article <dkvjhk$1dtg$1@digitaldaemon.com>, Ivan Senji says...
>>>
>>>>as opShl_r is defined in SimpleStack it has access to SimpleStack's private parts.
>>>>
>>>>Hope this helps in this neverending discussion :)
>>>
>>>
>>>Ok, this beats specifically the << operator overloading example, but there could
>>>be another similar example that doesn't use an operator and instead use just a
>>>member function. I'll think about it and post it (if I found one).  I doubt this
>>>specific example will puff out this nice discussion :)
>>>
>>>Tom
>>
>>Other than this what would be the case where you wish to grant some other (possibly library) class access to your classes private parts?
>>I think that one can adjust to this /limitation/ in D. I don't even think it is a limitation, in most cases i wish my classes have friendship relationship and it is easy to accomplish that (put them in the same module).
> 
> 
> I still think it looks very dirty to allow other classes from the same module to
> touch private members of each others 

In a strict OO sense friendship is allways dirty.

> (IMHO this could be a nice feature but not
> to be the default behavior, maybe it should have a keyword behind it). What
> about all the nice contract programming features? PRE/POST-conditions and
> invariants? (just asking). I feel that this permissive behavior goes one step
> back just after going a step forward with contract programming. If it's ugly to
> break the invariant of a class inside it, imagine breaking it from the outside.
> I sincerely distrust of the feature.
> 
> Quote: "in most cases i wish my classes have friendship relationship and it is
> easy to accomplish that". Yeah it's nice, but it'd be nicer if you could have more control of this in a
> more detailed way (e.g. adding more attributes or modifiers if it is necessary).
> I'm not saying this in-module-friendship is bad, just wish it to be optional to
> avoid the "paradox" it is (IMO) with respect to contract programming philosophy
> (not being to much of a scientist here, this is just what I perceive :) ). One
> advantage of friend keyword approach (e.g. C++) is that with it, you can control
> exactly WHO would you let to put their hands on the most intimate members of
> your object.
> 
> 
>>On the other topic i am starting to think that it would be nice to be able to split modules into more files. C# can now even split classes into more files but it is another discussion.
> 
> 
> PS: stop with the "if you don't want any other entity to gain access to your
> class privates, put it on another module!", THE WORLD ISN'T JUST BLACK OR WHITE.
> 

I think the problem here is (i had it too when i started with D) that you are trying/wanting to write C++, but this is another language and there are different ways to do things. The philosophy here is: make simple things simple and the D way gives you full control.
If you want to have friend classes in D you have to put them in the same model. The rule in C++ is different: if you want firendsip use the friendship keyword.

The D way is a little bit more limiting in that you can't make someone elses (or library) classes your firends but that would IMO be a bad design decision anyway.

D makes you stick to the OO paradigm when using other peoples classes (wich is ok), but also allows you to cheat OO in your code (also ok).

So your code in one module has default friendship, and doesn't it make sense? It is after all a group of related classes that are placed in one module.
And if you really really don't want any other entity to gain access to your class privates, put it on another module. :) HM, this sentence sounds familiar ;)

Conclusion: Give The-D-Way a chance, it might make sense to you in a while.

On Fri, 11 Nov 2005 00:24:50 +0100, Ivan Senji wrote:


[snip]
> And if you really really don't want any other entity to gain access to your class privates, put it on another module. :) HM, this sentence sounds familiar ;)

Yes, in principle I agree with you. But how can you provide access to parts of a class but not other parts of the class? With D, its the whole class or nothing. Splitting the class into two or more classes is not always a sensible thing to do either.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
11/11/2005 10:26:41 AM