[fpc-devel] Defenition of destructor behind property
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Fri Jun 10 02:45:47 CEST 2011
Joost van der Sluis schrieb:
> This construct is accepted by the compiler:
>
> Tdm = class(TDataModule)
> IBConnection1: TIBConnection;
> procedure DataModuleCreate(Sender: TObject);
> private
> function GetOnderdelen: TXMLDocument;
> public
> property Onderdelen: TXMLDocument read GetOnderdelen;
> destructor Destroy; override;
> end;
>
> Note the 'destructor' behind the property definition. Isn't this a bug?
Not really. The only strong (syntactical) order requirement exists for
fields, which can occur only at the begin of a visibility section. All
other declarations, of methods, properties etc., can be recognized by
their leading keywords, so that they can be mixed freely. What does not
mean that they ever *should* be mixed up (semantics)!
> (The Lazarus codetools choke on it)
This is what I'd consider a bug, in the codetools.
Above code looks to me as if Onderdelen [Dutch?] had been a field
before, and has been turned into a property later. In so far I'd vote
for sorting properties after fields, and before methods. Unfortunately
the *convention*, inherited from Delphi, is the opposite: properties
should come after methods.
The new Delphi syntax added Var, Const and Type sections to the class
declarations, so that fields can be recognized better (as Var), but I
don't like that bloat and all consequential problems :-(
DoDi
More information about the fpc-devel
mailing list