What's the point of having abstract classes in Delphi? Is there any use case? Hey, you can instantiate an abstract class just fine (no compiler error, warning, nor hint). You can even USE such object just fine

What's the point of having abstract classes in Delphi? Is there any use case? Hey, you can instantiate an abstract class just fine (no compiler error, warning, nor hint). You can even USE such object just fine

Yes, I know, the docs: http://docwiki.embarcadero.com/RADStudio/en/Classes_and_Objects_(Delphi)

Note: Delphi allows instantiating a class declared abstract, for backward compatibility, but this feature should not be used anymore.

So, Delphi got this new feature called abstract classes on Delphi 7. That was in 2002 IIRC. So fifteen years later all we got is a just a highlighted keyword?

I'm completely shocked

/rant off

Comments

  1. I'm not really sure what you're asking about. But at the risk of stating the obvious, ABC's (Abstract Base Classes) are essentially in some sense the equivalent of an interface. That is they allow the definition of a public API, a contract, that subclasses must adhere to without having to create empty implementations in your base class, and without having to use actual interfaces. Now you /could/ just declare a base class with empty methods etc which could be used in a similar way as an abstract base class to achieve the same, but arguably marking a class as abstract is more explicit, makes intent clearer and is tidier and reduces code clutter by avoiding needless/unwanted implementation bodies at the base class level. (It feels like I'm however obviously missing the point you're making, please explain what you're ranting about further!?)

    ReplyDelete
  2. I am/was sure that the compiler complained when you tried to create an abstract class (but a co-worker has got me doubting that now).

    ReplyDelete
  3. In OOP world, you cannot create an abstract class. The compiler should enforce this. At least, it should issue a warning

    I checked on D2010 and 10.2 Tokyo:

    type
    TAbstract = class abstract
    public
    procedure SayHello;
    end;

    procedure TAbstract.SayHello;
    begin
    Writeln('Hello abstract world!');
    end;

    var
    foo: TAbstract;
    begin
    foo := TAbstract.Create;
    try
    try
    foo.SayHello;
    Readln;
    except
    on E: Exception do
    Writeln(E.ClassName, ': ', E.Message);
    end;
    finally
    foo.Free;
    end;
    end.

    ReplyDelete
  4. Nicholas Ring the compiler warns if you create an instance of a class (no matter if abstract or not) that happens to have a virtual abstract method.

    ReplyDelete
  5. Agustin Ortu So, did you a error/warning from the compiler?

    Maybe that is what I am thinking of.

    ReplyDelete
  6. The code above should not compile. That's what I'm saying. Why it shouldn't compile? Because I'm creating an abstract class

    ReplyDelete
  7. Howerver, this:

    type
    TClassWithAbstractMethod = class
    public
    procedure SayHello; virtual; abstract;
    end;

    If you call create on this, you get a nice warning, because the class contains abstract methods.

    ReplyDelete
  8. I guess, for the abstract class issue, should raise a QP.
    As for the virtual method, it must be that I was thinking of.

    ReplyDelete
  9. Wasn't this a .net compatibily feature that has no meaning in other compilers?

    ReplyDelete
  10. David Heffernan Yes, though a compile-time warning to match the abstract method case seems reasonable to me.

    ReplyDelete
  11. Note an abstract class can be a valuable instrument to access some pointer structure by casting to it (Say a C++ class). That's enough use case for me. In this case the first example throws a warning (in FPC, no time to verify against Delphi yet) and an error when the class contains a method w/o implementation, the addition of virtual;abstract; when you try to instantiate it. But you can cast with it and that should be legal.... So there's a use case...

    ReplyDelete

Post a Comment