www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2946] New: Make 'abstract' mandatory if the class is intended to be abstract

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

           Summary: Make 'abstract' mandatory if the class is intended to be
                    abstract
           Product: D
           Version: unspecified
          Platform: PC
               URL: http://www.digitalmars.com/d/archives/digitalmars/D/Make
                    _abstract_mandatory_if_the_class_is_intended_to_be_abstr
                    act_70660.html
        OS/Version: All
            Status: NEW
          Keywords: accepts-invalid
          Severity: normal
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: gide nwawudu.com



 On Mon, 28 Apr 2008 10:11:23 -0300, Ary Borenszweig



don't mark a class as abstract, it can still be it if it contains an 
abstract method:

class Foo {

        abstract void someAbstract();

        void nonAbstract() {
        }

}

When designing a class, you have in mind whether the class is going to 
be abstract or not. If it's not going to be abstract, you want the 
compiler to help you by telling you "You made a mistake. This class is 
still abstract because you didn't implement method foo".

So I want to extend Foo with a class Bar, but I want Bar to be not abstract.

class Bar : Foo {
}

I compile, and it gives no error, of course. But I want there to be an 
error there. The only way I can get an error is by making a dummy 
function that instantiates Bar:

void blah() {
        Bar bar = new Bar();
}

main.d(14): Error: cannot create instance of abstract class Bar
main.d(14): Error: function someAbstract is abstract

The problems with this approach are two:
  - You have to make a dummy function to check whether you implemented 
Bar correctly.
  - You get two errors for each instantiation of Bar, if it's abstract 
(ugly).

Why not make "abstract" mandatory for a class if it's intended to be 
abstract, and the absence of "abstract" to mean "not abstract"? Java 
works this way, and I think it is for the reasons I mentioned.

Another advantage is that just by seeing the start of class definition 
you can tell whether a class is abstract or not. You don't have to see 
if any method is marked as abstract, or go to the superclasses to see if 
there is a method that is still not implemented.

(also, it would be nice if the compiler could tell you all the methods 
that still need an implementation, rather than just one)


--
May 06 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2946





------- Comment #1 from gide nwawudu.com  2009-05-06 10:17 -------
Another example.

main.d
------
class Foo1 {
    abstract void foo();
}

class Bar1 : Foo1 {
}

abstract class Foo2 {
    abstract void foo();
}

class Bar2 : Foo2 {
}

void main () { 
    debug {
        auto f1 = new Bar1;
        auto f2 = new Bar2;
    }
}

C:> dmd -w -debug main.d
main.d(17): Error: cannot create instance of abstract class Bar1
main.d(17): Error: function foo is abstract
main.d(18): Error: cannot create instance of abstract class Bar2
main.d(18): Error: function foo is abstract

Should not compile or at least give a warning, but does neither.
C:> dmd -w main.d


--
May 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2946


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com
           Severity|normal                      |enhancement
           Keywords|accepts-invalid             |diagnostic, spec




------- Comment #2 from smjg iname.com  2009-05-06 16:42 -------
http://www.digitalmars.com/d/2.0/attribute.html#abstract (and similarly 1.0)
"Classes become abstract if they are defined within an abstract attribute, or
if any of the virtual member functions within it are declared as abstract."

The compiler is behaving correctly, therefore this is an enhancement request.


--
May 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2946


Gide Nwawudu <gide nwawudu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #3 from Gide Nwawudu <gide nwawudu.com> 2010-07-27 07:17:03 PDT ---
*** Issue 4512 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: -------
Jul 27 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2946



--- Comment #4 from bearophile_hugs eml.cc 2010-10-29 05:01:02 PDT ---
(In reply to comment #2)

 The compiler is behaving correctly, therefore this is an enhancement request.



We need a different term to tell apart true enhancement requests (where someone
asks for a new feature or new subfeature) from bugs in the specs.

This is a case where the specs are suboptimal, so this is not a true
enhancement request, it's a way to fix a little mistake in the D specs.

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



--- Comment #5 from Stewart Gordon <smjg iname.com> 2010-10-30 05:57:20 PDT ---
(In reply to comment #4)

 This is a case where the specs are suboptimal, so this is not a true
 enhancement request, it's a way to fix a little mistake in the D specs.



Have you evidence that this is a mistake, i.e. not what Walter intended to
write?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2946



--- Comment #6 from bearophile_hugs eml.cc 2010-10-30 14:56:35 PDT ---
(In reply to comment #5)

 Have you evidence that this is a mistake, i.e. not what Walter intended to
 write?



I have no evidence, but regardless the origin of this current situation, the
Java design is the correct one (unless someone shows me otherwise) and I think
here it's better to modify D specs & implementation. And I think it's better to
do this change as soon as possible, before lot of D2 code is written, to reduce
troubles of fixing code later.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2946



--- Comment #7 from Stewart Gordon <smjg iname.com> 2010-10-30 17:22:30 PDT ---
Certainly the Java design is more sensible on this.  But "correct" in terms of
design is to some degree a matter of opinion.  There are a number of aspects of
D's design that I would consider mistakes - inheritance protection, archaic
switch syntax, implicit narrowing conversions just to name a few.  There are
probably lots filed here.  How would we label such issues on this basis,
anyway?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2010