www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2051] New: interfaces should allow private methods

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2051

           Summary: interfaces should allow private methods
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: andrei metalanguage.com


Consider: 

interface Foo
{
    private void bar();
}

class Bar : Foo
{
}

void main()
{
    Foo bar = new Bar;
    bar.bar;
}

This code has a link-time error. Removing "private" yields (correctly) a
compile-time error. So we have a bug already :o).

Adding a function void bar() {} to Bar keeps the link-time error in vigor,
whether or not the function is private. 

Now, if we want D to allow Sutter's NVI idiom
(http://www.gotw.ca/publications/mill18.htm) easily, it would need to enact the
following rules:

* A private method in an interface is part of that interface's table of
signatures.

* A class implementing a private method in an interface cannot graduate its
visibility (e.g. protected or public).

With these rules in place, D would support NVI very naturally. I think that's a
powerful paradigm that would lead to very expressive and robust interfaces.


--
Apr 28 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
d-bugmail puremagic.com wrote:

 Consider: 
 
 interface Foo
 {
     private void bar();
 }
 
 class Bar : Foo
 {
 }
 
 void main()
 {
     Foo bar = new Bar;
     bar.bar;
 }
 
 This code has a link-time error. Removing "private" yields (correctly) a
 compile-time error. So we have a bug already :o).


The error occurs because there's no implementation anywhere, so the 
vtable can't be completed. I'm assuming you're suggesting that this 
should be turned into a runtime error if no implementation is present 
anywhere, but this would be so much harder to update stuff once an 
interface is updated. I can't see any advantages of making this error 
runtime.
Apr 28 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2051






-------
By the current D spec private functions are never virtual. I'm pretty sure
that's why having a private function in an interface won't work.


--
Apr 28 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2051








 d-bugmail puremagic.com wrote:

 Consider: 
 
 interface Foo
 {
     private void bar();
 }
 
 class Bar : Foo
 {
 }
 
 void main()
 {
     Foo bar = new Bar;
     bar.bar;
 }
 
 This code has a link-time error. Removing "private" yields (correctly) a
 compile-time error. So we have a bug already :o).


 
 The error occurs because there's no implementation anywhere, so the 
 vtable can't be completed. I'm assuming you're suggesting that this 
 should be turned into a runtime error if no implementation is present 
 anywhere, but this would be so much harder to update stuff once an 
 interface is updated. I can't see any advantages of making this error 
 runtime.


The rest of my post clarifies my intent, which is not to make the error
runtime.


--
Apr 28 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2051








 By the current D spec private functions are never virtual. I'm pretty sure
 that's why having a private function in an interface won't work.


That explains part of the odd behavior - the compiler has a conflict of
interest of sorts. 

Now that I think of it, probably protected functions in an interface should be
enough. Consider:

interface Foo
{
    protected void bar();
}

class Bar : Foo
{
    void bar() {}
}

void main()
{
    Foo bar = new Bar;
    bar.bar;
}

This goes through, and is probably enough to make NVI work. There is the minor
annoyance that the class Bar can graduate visibility from protected to public,
but if it wants to, no language rule can stop it (e.g. Bar could expose the
method under a different name).

I will leave the bug opened because at a minimum the linker error should be
really a compile-time error. Alternatively, private functions in interfaces
could be allowed because they are technically final. Thanks all for your
comments.


--
Apr 28 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2051


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathias.baumann sociomantic
                   |                            |.com



*** Issue 6170 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 29 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2051


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |yebblies gmail.com
           Platform|x86                         |All
            Version|1.00                        |D1 & D2
         Resolution|                            |INVALID
         OS/Version|Linux                       |All



This is intentional, as by D's compilation model the body of the function may
be provided in another object file.  eg. When using .di files.

The original bug has been fixed by allowing final methods in interfaces.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 29 2012