Hi all,

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? (The Lazarus codetools choke on it)

Joost.

No.

Jonas

Joost van der Sluis hat am 9. Juni 2011 um 12:53 geschrieben:

It works here. 
 
Mattias

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

Again: It works here.

Mattias

In our previous episode, Hans-Peter Diettrich said:

For ordinary fields maybe. Union (case... of) fields must be at the end.

IIRC this is currently broken in FPC.

This is not a strong requirement, because "case" is the keyword for such sections.

DoDi