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
next sibling 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 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
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 =?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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
I mean, the 'package' access modifier.
Oct 18 2012
prev sibling next 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 "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
prev sibling next sibling 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 next 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
prev sibling next sibling parent "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
prev sibling 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.

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.

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.

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