Hello,

I have the following test program:

program AbstractTest;
{$MODE ObjFpc}{$H+}
uses Classes;
type
   TAbstractClass = class abstract(TObject)
   end;
var
   MyAbstractClass: TAbstractClass = nil;
begin
   MyAbstractClass := TAbstractClass.Create;
   MyAbstractClass.Free;
end.

I thougt this would cause a compiler error, while creating a abstract class. Surprisingly it compiles, even without a warning.

Do I have to use any compiler switches or is there no sense in using the abstract keyword for a class?

Michael

'Casting' a class as abstract is curious syntax. What led you to think of that? But obviously the compiler knows it.
As soon as you add an abstract method the compiler will give a warning.

Howard

Howard Page-Clark wrote

> TAbstractClass = class abstract(TObject) 'Casting' a class as abstract is curious syntax. What led you to think of that? But obviously the compiler knows it.

This is no casting, it is the new abstract class syntax coming from delphi.

As soon as you add an abstract method the compiler will give a warning.

Yes, this behaviour I know. But I would prefer an error for abstract classes. I was hoping, that the class abstract keyword led to this error.

Michael

08.01.13, 19:48, Michael Fuchs пишет:

Abstract class feature is implemented the same way as it is done in delphi. In delphi it does not raise any error, so it works in FPC. The only limitation is that you can't both set sealed and abstract for the same class.

Maybe later delphi will come with some extra checks for abstract classes and then FPC will follow.

Best regards,
Paul Ishenin

Hm, and how about a pioneer solution?

For example a compiler error in {$MODE ObjFpc} and the actual behaviour in {$MODE Delphi}. That would not break compatibility, but gets a nice feature for FPC.

Michael

Michael Fuchs wrote

For example a compiler error in {$MODE ObjFpc} and the actual behaviour in {$MODE Delphi}. That would not break compatibility, but gets a nice feature for FPC.

+1
The current behaviour (even if Delphi compatible) seems just wrong - totally defeats the point of "abstract" in object design!

Regards,
- Graeme -

Graeme Geldenhuys wrote

+1 The current behaviour (even if Delphi compatible) seems just wrong - totally defeats the point of "abstract" in object design!

What is the best way for a discussion on this? Should I create a feature request in bugtracker?

Michael

09.01.13, 6:26, Michael Fuchs пишет:

What is the best way for a discussion on this? Should I create a feature request in bugtracker?

First create a desired implementation with a patch.

Best regards,
Paul Ishenin

Well, I may overlook something, of course, but I believe that this request probably shouldn't fall into the category of things which are difficult/time-demanding for the compiler people (if it should be implemented, of course, but I haven't seen any arguments against it raised yet). If you believe that it may be difficult, please clarify it.

I understand that the requested behaviour needs to be described well, of course, but if my understanding is correct, requiring the original poster to implement it himself may not be appropriate in this case (not very efficient - a lot of learning effort necessary for the original poster compared to hopefully limited effort for existing core team members). It is important to notify the poster that filing the feature request doesn't guarantee that it gets implemented (soon or ever). Nevertheless, _requiring_ all suggestions to be accompanied with a patch is IMHO too much.

Tomas

Paul Ishenin wrote

> What is the best way for a discussion on this? Should I create a feature > request in bugtracker? First create a desired implementation with a patch.

I would do it, if I only know where to start. Unfortunately are my experiences in compiler programming equal to zero. Is there a document how to start? Maybe a architecture diagram?

BTW: How long does it normally take, until a patch is integrated (or declined)? Two month ago I submitted a patch for a bug in SQLite3db. Is it better to wait or to inquire?

Sorry for the dumb questions, this is new territory for me.

Michael

[1] - http://bugs.freepascal.org/view.php?id=23247

I started from compiler sources. You need mostly parser part - that units start from 'p'. For example object types (objects, classes, interfaces, ... too) parsing is located in pdecobj.pas.

Abstract modifier parsing is located in parse_object_options method - see for include(.., oo_is_abstract).

Then you need something similar like a warning which is raised when a class with abstract members is created. Search where this warning is raised. Add something similar but with check for abstract class there. But only not for delphi modes.

If patch from a bug tracker is not noticed just write a mail. Most of developers read their mails although not everybody check the bug tracker every day.

You will get valuable experience in any case even if your patch is rejected ;)

Best regards,
Paul Ishenin