Discussion:
[fpc-pascal] Abstract classes ignored
Ryan Joseph via fpc-pascal
2021-04-17 18:30:21 UTC
Permalink
From the documentation: "An abstract class is a class that cannot be instantiated directly. Instead, a descendent class must always be instantiated. However, for Delphi compatibility, the compiler ignores this directive."

Why does this get ignored and what does this have to do with Delphi? I personally would like for this to actually work and give a compiler error if you instantiate the abstract class.

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bi
Sven Barth via fpc-pascal
2021-04-17 21:09:12 UTC
Permalink
Post by Ryan Joseph via fpc-pascal
From the documentation: "An abstract class is a class that cannot be instantiated directly. Instead, a descendent class must always be instantiated. However, for Delphi compatibility, the compiler ignores this directive."
Why does this get ignored and what does this have to do with Delphi? I personally would like for this to actually work and give a compiler error if you instantiate the abstract class.
The compiler will generate a warning in case you instantiate a class
that is abstract or has abstract methods. You can escalate these
warnings to errors if you need:

=== code begin ===

program tabstract;

{$MODE OBJFPC}
{$WARN CONSTRUCTING_ABSTRACT ERROR}

type
  TAbstract1 = class abstract
  end;

  TAbstract2 = class
    procedure Test; virtual; abstract;
  end;

var
  a1: TAbstract1;
  a2: TAbstract2;
begin
  a1 := TAbstract1.Create;
  a2 := TAbstract2.Create;
end.

=== code end ===

This will generate two (different) errors.

With this we're allowing more than Delphi does (which warns in the
second case, but the warning can not be escalated to error and does not
warn for the first case at all), but Delphi compatbility is more
important here, thus the default is a warning and not an error. This
will not be changed.

Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-
Ryan Joseph via fpc-pascal
2021-04-18 02:34:44 UTC
Permalink
It's probably not practical to put that warning into all potential files but a warning is still probably good enough as a reminder. It's curious though why it's not an error by default, because if the class is abstract and you instantiate it and try to use it things are going to fail anyways so why does the compiler allow it in the first place?

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists
C Western via fpc-pascal
2021-04-18 10:31:17 UTC
Permalink
Post by Ryan Joseph via fpc-pascal
It's probably not practical to put that warning into all potential files but a warning is still probably good enough as a reminder. It's curious though why it's not an error by default, because if the class is abstract and you instantiate it and try to use it things are going to fail anyways so why does the compiler allow it in the first place?
Regards,
Ryan Joseph
_______________________________________________
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
My own code will have cases where I have only implemented some of the
abstract methods for some classes, in principle because the code is
incomplete, but there are also case where it never makes sense to
implement them and calling them indicates a logical error elsewhere in
the code.

Colin

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/l
Graeme Geldenhuys via fpc-pascal
2021-04-18 15:54:22 UTC
Permalink
Post by C Western via fpc-pascal
but there are also case where it never makes sense to
implement them and calling them indicates a logical error elsewhere in
the code.
So do the logical thing... Throw an exception! Don't promote a faulty
compiler. Fix your code instead.


Regards,
Graeme
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.or
Sven Barth via fpc-pascal
2021-04-18 20:54:40 UTC
Permalink
Post by Graeme Geldenhuys via fpc-pascal
Post by C Western via fpc-pascal
but there are also case where it never makes sense to
implement them and calling them indicates a logical error elsewhere in
the code.
So do the logical thing... Throw an exception! Don't promote a faulty
compiler. Fix your code instead.
Calling an abstract method will already result in an EAbstractError to be
thrown.

Regards,
Sven
Sven Barth via fpc-pascal
2021-04-18 11:00:49 UTC
Permalink
Post by Ryan Joseph via fpc-pascal
It's probably not practical to put that warning into all potential files but a warning is still probably good enough as a reminder. It's curious though why it's not an error by default, because if the class is abstract and you instantiate it and try to use it things are going to fail anyways so why does the compiler allow it in the first place?
As I have said: Delphi compatibility.

Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bi
Ryan Joseph via fpc-pascal
2021-04-18 17:58:36 UTC
Permalink
Post by Sven Barth via fpc-pascal
As I have said: Delphi compatibility.
This would have been a good candidate to put behind the delphi mode switch but I'm sure there is a reason for this also.

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.
Sven Barth via fpc-pascal
2021-04-19 05:28:24 UTC
Permalink
Post by Ryan Joseph via fpc-pascal
Post by Sven Barth via fpc-pascal
As I have said: Delphi compatibility.
This would have been a good candidate to put behind the delphi mode switch but I'm sure there is a reason for this also.
Nowadays: backwards compatibility.

Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listin
Ryan Joseph via fpc-pascal
2021-04-19 15:18:14 UTC
Permalink
Post by Sven Barth via fpc-pascal
Nowadays: backwards compatibility.
backwards compatibility strikes again. :)

Regards,
Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/list

Graeme Geldenhuys via fpc-pascal
2021-04-18 15:55:54 UTC
Permalink
Post by Sven Barth via fpc-pascal
but Delphi compatbility is more
important here, thus the default is a warning and not an error.
How is this beneficial? The compiler should help the developer, but here
it was decided that it's beneficial for the program to crash at runtime,
because follow the broken Delphi compiler is more important! *shrug*

Such decisions really make me worry about the future of FPC. It ends up
being NO better than Delphi, so why bother using FPC then. Stick to
Delphi instead.

Regards,
Graeme

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/
Jonas Maebe via fpc-pascal
2021-04-18 16:08:34 UTC
Permalink
Post by Graeme Geldenhuys via fpc-pascal
Post by Sven Barth via fpc-pascal
but Delphi compatbility is more
important here, thus the default is a warning and not an error.
How is this beneficial? The compiler should help the developer,
People who want to compile code in both FPC and Delphi are developers
too. People who want to use their knowledge of Delphi to program in FPC
are developers too.

You can never make everyone happy, and sometimes we go for
incompatibility by default, and sometimes we don't. In this case, you
can easily make it an error yourself with {$warn 4046 error}.
Post by Graeme Geldenhuys via fpc-pascal
Such decisions really make me worry about the future of FPC. It ends up
being NO better than Delphi, so why bother using FPC then. Stick to
Delphi instead.
It's not like this is a new policy that you just discovered, so please
stop already with the flamebait drama about how this makes you worry
about the future of FPC.


Jonas
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinf
Jonas Maebe via fpc-pascal
2021-04-18 19:19:11 UTC
Permalink
Post by Jonas Maebe via fpc-pascal
In this case, you
can easily make it an error yourself with {$warn 4046 error}.
Correction: that's make it an error to construct a classes that contain
abstract methods. For abstract classes, it's {$warn 4122 error}


Jonas
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lis
Sven Barth via fpc-pascal
2021-04-18 20:53:41 UTC
Permalink
Post by Jonas Maebe via fpc-pascal
Post by Jonas Maebe via fpc-pascal
In this case, you
can easily make it an error yourself with {$warn 4046 error}.
Correction: that's make it an error to construct a classes that contain
abstract methods. For abstract classes, it's {$warn 4122 error}
Or as I had written already: {$WARN CONSTRUCTING_ABSTRACT ERROR}. This will
switch both warnings to error.

Regards,
Sven
Travis Siegel via fpc-pascal
2021-04-18 17:56:12 UTC
Permalink
Post by Graeme Geldenhuys via fpc-pascal
Post by Sven Barth via fpc-pascal
but Delphi compatbility is more
important here, thus the default is a warning and not an error.
How is this beneficial? The compiler should help the developer, but here
it was decided that it's beneficial for the program to crash at runtime,
because follow the broken Delphi compiler is more important! *shrug*
Such decisions really make me worry about the future of FPC. It ends up
being NO better than Delphi, so why bother using FPC then. Stick to
Delphi instead.
If you're willing to pay for me to obtain a delphi license, then I'd
happily switch.  Seeing as how they charge over a thousand dollars even
during their supposed sales, I have no interest in spending that kind of
money for an environment that FPC offers for free. That means I don't
have to spend my limited income on a license for a program I use a few
times a year.

Admittedly, part of the reason I use it so rarely is because I really
need to dig into it's gui and tcp capabilities (I program from the
ocmmand prompt, but being able to generate gui screens on the fly would
be nice).  I know Delphi can do this, but the last time I asked them
about pricing, they told me it'd cost $1000 for just delphi 7, and that
only costed $995 when it first came out, nearly 20 years ago.  I refuse
to support that kind of price gouging, even if I could afford it.

But, as I said, if you're willing to foot the bill, I'd happily use it,
as it does indeed have (some) advantages.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pasca
Bart via fpc-pascal
2021-04-18 18:13:11 UTC
Permalink
On Sun, Apr 18, 2021 at 7:56 PM Travis Siegel via fpc-pascal
... but the last time I asked them
about pricing, they told me it'd cost $1000 for just delphi 7, and that
only costed $995 when it first came out, nearly 20 years ago.
Wow!
Long time ago, I bought Delphi2 (it was bundled with Delphi 1, and
that was the one I needed, since I was on Win 3.10) for about ƒ200.
(€1.00 = ƒ2.20).
It came with a full manual (on paper that is).

Those were the days....
--
Bart
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-p
Loading...