www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Friends?

reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
Hey guys!

I think I understand the reasoning behind the idea that classes 
in the same module are automatically "friends", but why isn't 
there any way to have this sort of relationship between classes 
outside of a module? I feel like there are times when it doesn't 
always make sense to have two(or more) classes in the same 
module, but you would still need to make them interact like 
"friends."

Is there any kind of work around for this functionality?

And in case you were curious, my main problem with this is that I 
think it is a lot cleaner when writing code and easier to manage 
my projects when I can split things up into different files. I'm 
currently working on a wrapper for a C++ api and started wishing 
I could do this a few days ago.
Oct 18 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, October 18, 2012 10:09:46 Jeremy DeHaan wrote:

 Is there any kind of work around for this functionality?


The package access modifier.

- Jonathan M Davis
Oct 18 2012
parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Thursday, 18 October 2012 at 08:12:42 UTC, Jonathan M Davis 
wrote:

 On Thursday, October 18, 2012 10:09:46 Jeremy DeHaan wrote:

 Is there any kind of work around for this functionality?


 The package access modifier.

 - Jonathan M Davis


You, good sir, are now my new best friend.
Oct 18 2012
next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, Oct 18, 2012 at 11:12 AM, Jeremy DeHaan
<dehaan.jeremiah gmail.com> wrote:

 On Thursday, 18 October 2012 at 08:12:42 UTC, Jonathan M Davis wrote:

 On Thursday, October 18, 2012 10:09:46 Jeremy DeHaan wrote:

 Is there any kind of work around for this functionality?



 The package access modifier.

 - Jonathan M Davis



 You, good sir, are now my new best friend.


Does it work? I thought it was not implemented.
Oct 18 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-18 19:57, Philippe Sigaud wrote:


 Does it work? I thought it was not implemented.


Define "work". They're not virtual, which this would imply:

"All non-static non-private non-template member functions are virtual."

http://dlang.org/function.html#virtual-functions

-- 
/Jacob Carlborg
Oct 18 2012
next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
I mean, the 'package' access modifier.
Oct 18 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-18 20:51, Philippe Sigaud wrote:

 I mean, the 'package' access modifier.


So did I.

class Foo
{
     package void foo () {}
}

Would, according to the spec, imply a virtual method. But as Jonathan 
said, this is a bug in the spec.

-- 
/Jacob Carlborg
Oct 18 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 19-10-2012 08:23, Jacob Carlborg wrote:

 On 2012-10-18 20:51, Philippe Sigaud wrote:

 I mean, the 'package' access modifier.


 So did I.

 class Foo
 {
      package void foo () {}
 }

 Would, according to the spec, imply a virtual method. But as Jonathan
 said, this is a bug in the spec.


What? How is this not an implementation bug? An access modifier 
shouldn't have anything to do with whether a method is virtual. If 
people want to have a class hierarchy with virtual functions at package 
level, let them. This is the most ridiculous arbitrary restriction I 
have seen to date. :|

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 19 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, October 19, 2012 20:01:20 Alex Rønne Petersen wrote:

 On 19-10-2012 08:23, Jacob Carlborg wrote:

 On 2012-10-18 20:51, Philippe Sigaud wrote:

 I mean, the 'package' access modifier.


 
 So did I.
 
 class Foo
 {
 
 package void foo () {}
 
 }
 
 Would, according to the spec, imply a virtual method. But as Jonathan
 said, this is a bug in the spec.


 
 What? How is this not an implementation bug? An access modifier
 shouldn't have anything to do with whether a method is virtual. If
 people want to have a class hierarchy with virtual functions at package
 level, let them. This is the most ridiculous arbitrary restriction I
 have seen to date. :|


No. Access level in D has _everything_ to do with whether a function is 
virtual or not, because unlike C++, it provides no way to explicitly indicate 
virtual. In particular, private _must_ be non-virtual, or we have serious 
issues. Now, whether package in particular should be virtual or not is 
arguably arbitrary, but since the only reason to have virtual functions is 
inheritence, it _does_ make some sense that only public and protected 
functions would be virtual. You can go look for discussions on it in the main 
newsgroup though if you want to see Walter and Andrei's exact reasoning on the 
matter.

- Jonathan M Davis
Oct 19 2012
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 19 Oct 2012 14:36:59 -0400
"Jonathan M Davis" <jmdavisProg gmx.com> wrote:


 On Friday, October 19, 2012 20:01:20 Alex R=F8nne Petersen wrote:

 On 19-10-2012 08:23, Jacob Carlborg wrote:

 On 2012-10-18 20:51, Philippe Sigaud wrote:

 I mean, the 'package' access modifier.


=20
 So did I.
=20
 class Foo
 {
=20
 package void foo () {}
=20
 }
=20
 Would, according to the spec, imply a virtual method. But as
 Jonathan said, this is a bug in the spec.


=20
 What? How is this not an implementation bug? An access modifier
 shouldn't have anything to do with whether a method is virtual. If
 people want to have a class hierarchy with virtual functions at
 package level, let them. This is the most ridiculous arbitrary
 restriction I have seen to date. :|


=20
 No. Access level in D has _everything_ to do with whether a function
 is virtual or not, because unlike C++, it provides no way to
 explicitly indicate virtual.


Sure we do. By not adding the word 'final'. (May not be "explicit" in a
strict pedantic sense, but it's close enough.)



 In particular, private _must_ be
 non-virtual, or we have serious issues.


I was just about to that that I'd heard this before and agreed with
it, but something just occurred to me:

That would be true if our "private" was like C++'s private and meant
"accessible by this *class* only". Problem is, D doesn't even *have*
that kind of private. Unlike C++, in D, you *can* have outside
code accessing a class's private members. I see no apparent reason why
a private implementation shouldn't be allowed to use inheritance if it
so chooses.



 Now, whether package in
 particular should be virtual or not is arguably arbitrary, but since
 the only reason to have virtual functions is inheritence, it _does_
 make some sense that only public and protected functions would be
 virtual.


I don't see how that makes sense unless the *only* other option besides
public and protected is a C++-style "private". But that's not the case
in D. In D we also have package and a D-style "private" which is really
more of a "module" than actual "private".



 You can go look for discussions on it in the main newsgroup
 though if you want to see Walter and Andrei's exact reasoning on the
 matter.
=20
 - Jonathan M Davis
Oct 19 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, October 18, 2012 20:42:08 Jacob Carlborg wrote:

 On 2012-10-18 19:57, Philippe Sigaud wrote:

 Does it work? I thought it was not implemented.


 
 Define "work". They're not virtual, which this would imply:
 
 "All non-static non-private non-template member functions are virtual."
 
 http://dlang.org/function.html#virtual-functions


That's a spec bug. Walter and Andrei have both confirmed that package functions 
are not intended to be virtual and that that won't be changing.

- Jonathan M Davis
Oct 18 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 Does it work? I thought it was not implemented.


Hmm. I don't know what it's current state is. There _is_ a long-standing bug 
on it in bugzilla ( http://d.puremagic.com/issues/show_bug.cgi?id=143 ) which 
is still open. I had forgotten about it. But the bug is that package doesn't 
restrict when it's supposed to as opposed to restricting when it's not 
supposed to, so it'll work in that you can use it correctly and have your code 
work, but it won't catch incorrect usage, and your code which uses it 
incorrectly will break once it's fixed.

- Jonathan M Davis
Oct 18 2012
parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Thursday, 18 October 2012 at 20:44:42 UTC, Jonathan M Davis 
wrote:

 Does it work? I thought it was not implemented.


 Hmm. I don't know what it's current state is. There _is_ a 
 long-standing bug
 on it in bugzilla ( 
 http://d.puremagic.com/issues/show_bug.cgi?id=143 ) which
 is still open. I had forgotten about it. But the bug is that 
 package doesn't
 restrict when it's supposed to as opposed to restricting when 
 it's not
 supposed to, so it'll work in that you can use it correctly and 
 have your code
 work, but it won't catch incorrect usage, and your code which 
 uses it
 incorrectly will break once it's fixed.

 - Jonathan M Davis


It seems to be working for me. Things within the same package can 
access those members and things outside can't. The compiler 
complained when I tried.
Oct 18 2012
prev sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, Oct 18, 2012 at 10:44 PM, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Does it work? I thought it was not implemented.


 Hmm. I don't know what it's current state is. There _is_ a long-standing bug
 on it in bugzilla ( http://d.puremagic.com/issues/show_bug.cgi?id=143 ) which
 is still open. I had forgotten about it. But the bug is that package doesn't
 restrict when it's supposed to as opposed to restricting when it's not
 supposed to, so it'll work in that you can use it correctly and have your code
 work, but it won't catch incorrect usage, and your code which uses it
 incorrectly will break once it's fixed.


Ah, I see. I filed it mentally into my 'non-implemented-see-later'
slot back in 2008 or 2009 when I began with D :)
Oct 19 2012