> On Apr 18, 2021, at 11:28 PM, Sven Barth wrote:
>
> Nowadays: backwards compatibility.
backwards compatibility strikes again. :)
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org
Am 18.04.2021 um 19:58 schrieb Ryan Joseph via fpc-pascal:
On Apr 18, 2021, at 5:00 AM, Sven Barth wrote:
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 compa
Graeme Geldenhuys via fpc-pascal schrieb
am So., 18. Apr. 2021, 17:54:
>
> On 18/04/2021 11:31 am, C Western via fpc-pascal wrote:
> > 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 logi
Jonas Maebe via fpc-pascal schrieb am
So., 18. Apr. 2021, 21:19:
> On 18/04/2021 18:08, Jonas Maebe via fpc-pascal wrote:
> > 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
On 18/04/2021 18:08, Jonas Maebe via fpc-pascal wrote:
> 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
___
On Sun, Apr 18, 2021 at 7:56 PM Travis Siegel via fpc-pascal
wrote:
>... 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 w
> On Apr 18, 2021, at 5:00 AM, Sven Barth wrote:
>
> 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
___
fp
On 4/18/2021 11:55 AM, Graeme Geldenhuys via fpc-pascal wrote:
On 17/04/2021 10:09 pm, Sven Barth via fpc-pascal wrote:
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 wa
On 18/04/2021 17:55, Graeme Geldenhuys via fpc-pascal wrote:
> On 17/04/2021 10:09 pm, Sven Barth via fpc-pascal wrote:
>> 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
On 17/04/2021 10:09 pm, Sven Barth via fpc-pascal wrote:
> 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 run
On 18/04/2021 11:31 am, C Western via fpc-pascal wrote:
> 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 ins
Am 18.04.2021 um 04:34 schrieb Ryan Joseph via fpc-pascal:
On Apr 17, 2021, at 3:09 PM, Sven Barth wrote:
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:
It's probably not
On 18/04/2021 03:34, Ryan Joseph via fpc-pascal wrote:
On Apr 17, 2021, at 3:09 PM, Sven Barth wrote:
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:
It's probably not prac
> On Apr 17, 2021, at 3:09 PM, Sven Barth wrote:
>
> 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:
It's probably not practical to put that warning into all potential fi
Am 17.04.2021 um 20:30 schrieb 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 thi
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
pe
On Mon, Jan 21, 2013 at 10:59 PM, Graeme Geldenhuys
wrote:
> As I said in the other thread - it is a bug! Completely defeats the
> design principal of what "abstract class or method" means.
>
> FPC should raise an error. I don't care what Delphi does - it's wrong.
I agree, it's awkward to just le
On 01/21/13 22:28, Leonardo M. Ramé wrote:
>
> As far as I remember Delphi has the same behavior.
As I said in the other thread - it is a bug! Completely defeats the
design principal of what "abstract class or method" means.
FPC should raise an error. I don't care what Delphi does - it's wrong.
>
> From: Howard Page-Clark
>To: FPC users list
>Sent: Sunday, January 20, 2013 8:37 PM
>Subject: [fpc-pascal] abstract classes
>
>FPC allows the Delphi-compatible "class abstract" syntax, but does not seem to
>prevent i
On 21 Jan 2013, at 00:37, Howard Page-Clark wrote:
> FPC allows the Delphi-compatible "class abstract" syntax, but does not seem
> to prevent instantiation of such a class.
> The following code compiles and runs satisfactorily (FPC version 2.6.0)
> Does trunk prevent this compiling?
No. Also se
FPC allows the Delphi-compatible "class abstract" syntax, but does not
seem to prevent instantiation of such a class.
The following code compiles and runs satisfactorily (FPC version 2.6.0)
Does trunk prevent this compiling?
program Project1;
{$mode objfpc}{$H+}
type
TAbstractClass = class a
21 matches
Mail list logo
