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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
