[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