Recent

Author Topic: Abstract classes  (Read 15500 times)

Imants

  • Full Member
  • ***
  • Posts: 181
Abstract classes
« on: July 15, 2012, 01:54:13 pm »
Is it ok that allows to create abstract classes? Like
 
  TAbstractClass = class abstract(TObject)
  public
    procedure Test; virtual; abstract;
  end;

var
  FTest: TAbstractClass;
begin
  FTest := TAbstractClass.Create; //shouldn't here need to bee an error
end.

but compiler compiles it and gives only a warning.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8266
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Abstract classes
« Reply #1 on: July 15, 2012, 02:45:15 pm »
For me, it should indeed be an error. But maybe the developers have another thought, Delphi compatibility for instance (I don't know how it behaves it Delphi either).

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8729
  • FPC developer.
Re: Abstract classes
« Reply #2 on: July 15, 2012, 04:10:27 pm »
Yes that is ok. Sometimes classes contain abstract methods only for specific purposes (like streaming).

If you don't stream the relevant class you don't need to define them. If it was an error you would have to.   

Also it would create problems with versioning, e.g. when an abstract methods is added to a baseclass in a new FPC version, all old code wouldn't compile anymore till the new method was overriden.

eny

  • Hero Member
  • *****
  • Posts: 1609
Re: Abstract classes
« Reply #3 on: July 15, 2012, 06:59:36 pm »
Yes that is ok. Sometimes classes contain abstract methods only for specific purposes (like streaming).
There is a bit more to it.

From a pure OO perspective abstract classes should not (or better: can not!) be instantiated because it is unknown how the abstract methods are supposed to work. Hence the abstract classification. So it is a bad idea to instantiate abstract classes or allow them to be instantiated.
They serve an important purpose: to be at the top of an inheritance hierarchy.

Luckily the FPC compiler does recognizes them although they are only flagged as warnings (at least that's something).

If you want to have methods that 'do not have a purpose yet but they might', implement them as virtual and create an empty body.
(Although the programming paradigm YAGNI also applies.)

Quote
Also it would create problems with versioning, e.g. when an abstract methods is added to a baseclass in a new FPC version, all old code wouldn't compile anymore till the new method was overriden.
True. Thats the reason why this shouldn't happen that often with classes already in usage. Especially in the LCL.
And if it does happen it is good the compiler recognizes it so the inheriting classes can be adapted.
(Or the the method not being defined as abstract but merely virtual as described above.)
All posts based on: Win10 (Win64); Lazarus 2.0.10 'stable' (x64) unless specified otherwise...

KpjComp

  • Hero Member
  • *****
  • Posts: 680
Re: Abstract classes
« Reply #4 on: July 15, 2012, 07:14:14 pm »
Delphi Allows it.

Imants

  • Full Member
  • ***
  • Posts: 181
Re: Abstract classes
« Reply #5 on: July 15, 2012, 08:23:03 pm »
Also it would create problems with versioning, e.g. when an abstract methods is added to a baseclass in a new FPC version, all old code wouldn't compile anymore till the new method was overriden.

I tried add abstract methods to base classes. And hoped that compiler would create errors in places where I create these classes like in java but it didn't then I masked all class abstract by writing "class abstract" it didn't do a thing either. So what is purpose of "abstract" token.

I understand that for old compatibility pascal allows to create classes with abstract methods but what use to allow to create class which is declared as abstract it self.

eny

  • Hero Member
  • *****
  • Posts: 1609
Re: Abstract classes
« Reply #6 on: July 15, 2012, 08:26:29 pm »
I understand that for old compatibility pascal allows to create classes with abstract methods but what use to allow to create class which is declared as abstract it self.
None.
All posts based on: Win10 (Win64); Lazarus 2.0.10 'stable' (x64) unless specified otherwise...

KpjComp

  • Hero Member
  • *****
  • Posts: 680
Re: Abstract classes
« Reply #7 on: July 15, 2012, 09:58:14 pm »
Quote
but what use to allow to create class which is declared as abstract it self.

I think because how can the compiler always know?.
eg.

Code: [Select]
type
  TSomething = class
     function SomeAbstractMethod:boolean; virtual; abstract;
  end;
  TSomethingClass = class of TSomething;

procedure CreateSomething(c:TSomethingClass);
var
  x:TSomething;
begin
  x := c.Create;  //how does the compiler know it's not got no overridden abstract methods?
end;

Also what if you wanted to  manipulate VMT's manually?, if you can't even create the class this option is out the window.

Also making empty Virtual methods, will of course make more redundant code, at least with virtual abstract all methods share the same code.  And in this case gives you a nice runtime error.

totya

  • Hero Member
  • *****
  • Posts: 635
Re: Abstract classes
« Reply #8 on: March 27, 2018, 10:23:02 pm »
Yes, confirmed, abstract directive doesn't work, lazarus 1.6.4.

Blaazen

  • Hero Member
  • *****
  • Posts: 2918
  • POKE 54296,15
    • Eye-Candy Controls
Re: Abstract classes
« Reply #9 on: March 27, 2018, 11:09:35 pm »
@ Yes, confirmed, abstract directive doesn't work, lazarus 1.6.4.

What does it mean, "doesn't work"?

When I try to create abstract class with abstract method I got many warnings from compiler (one for each abstract method and one for the class itself (unit1.pas(36,38) Warning: Creating an instance of abstract class "TBaseScrollControl")). It is same for mode delphi and objfpc.
Even more, it depends on compiler, version of Lazarus is irrelevant.
From my point of view, it works well.
Lazarus 2.1.0 r63881 FPC 3.3.1 r40507 x86_64-linux-qt Chakra, Qt 4.8.7/5.13.2, Plasma 5.17.3
Lazarus 1.8.2 r57369 FPC 3.0.4 i386-win32-win32/win64 Wine 3.21

Try Eye-Candy Controls: https://sourceforge.net/projects/eccontrols/files/

jamie

  • Hero Member
  • *****
  • Posts: 3526
Re: Abstract classes
« Reply #10 on: March 27, 2018, 11:35:13 pm »
Classes with Abstracts in them are great, cause you do not always need to implement all of them
and it is clearly documented in my old Delphi that it is the case and will generate a fault if you attempt to
execute a non implemented abstract..

 If guess if it bothers you, you could direct all unused abstracts to dummy methods..
The only true wisdom is knowing you know nothing

totya

  • Hero Member
  • *****
  • Posts: 635
Re: Abstract classes
« Reply #11 on: March 27, 2018, 11:36:58 pm »
What does it mean, "doesn't work"?

This is mean, I doesn't got compiler warnings or any, if a descendant class doesn't contain the abstract method.

I try to create sample later... Thanks.

ASerge

  • Hero Member
  • *****
  • Posts: 1671
Re: Abstract classes
« Reply #12 on: March 28, 2018, 01:17:37 am »
I think because how can the compiler always know?.
You have an unfortunate example. If an instance is created through a class reference, then it is correct that it does not know the exact class. But in the case of "TSomething.Create" there are no other options, and in theory, this should be a mistake. But for compatibility with Delphi it is left as is.

jamie

  • Hero Member
  • *****
  • Posts: 3526
Re: Abstract classes
« Reply #13 on: March 28, 2018, 01:45:45 am »
if memory serves I think all undefined abstracts point to a default Raise message, so in reality they do point to
something  :)
The only true wisdom is knowing you know nothing

Thaddy

  • Hero Member
  • *****
  • Posts: 10467
Re: Abstract classes
« Reply #14 on: March 28, 2018, 12:56:39 pm »
in theory, this should be a mistake. But for compatibility with Delphi it is left as is.
Just curious? Which theory? Because that is not true. There is -more than a single - a necessity for it.
Suppose you would introduce an abstract method in a derived class? That should be legal and the class should be able to compile.
Object Pascal abstract classes should not be confused with C++ pure virtual. (You can use interfaces for that, though)

Since OP derived from a class that is NOT abstract it has to obey simple OOP principles and respect any virtual method that is not abstract.
Since TObject is not a virtual abstract class any derived classes are not fully "abstract" .
« Last Edit: March 28, 2018, 01:01:19 pm by Thaddy »
When you ask a question that is actually answered in the documentation, you are either lazy or a moron.

 

TinyPortal © 2005-2018