Zugriff auf Unterklasse absichern

[bra]

Es wird ja schon beim Übergeben an die Funktion ausgewertet, da kracht es schon

[DeddyH]

Japp, siehe mein Edit.

[Zacherl]

Zitat von bra:

Es wird ja schon beim Übergeben an die Funktion ausgewertet, da kracht es schon

Achja logisch. Zu viel C programmiert in letzter Zeit

Könnte man sich höchstens mit anonymen Methoden noch was zusammenbasteln:

Delphi-Quellcode:

class function TTernaryOp.Execute<T>(Condition: Boolean; const ATrue, AFalse: TFunc<T>): T;
begin
  if Condition then
  begin
    Result := ATrue;
  end else
  begin
    Result := AFalse;
  end;
end;

oder falls ausreichend auch:
class function TTernaryOp.Execute<T>(Condition: Boolean; const ATrue: TFunc<T>; const AFalse: T): T; Ist natürlich alles nicht wirklich schön.

Edit: Roter Kasten?

[Uwe Raabe]

Ich will auch noch meinen Senf dazu geben

Man kann dem Property Name in TMethode auch einen smarten Getter verpassen, dann spart man sich das Null-Objekt:

Delphi-Quellcode:

type
  TMethode = class
  private
    FName: String;
    function GetName: String;
  public
    property Name: String read GetName write FName;
  end;

function TMethode.GetName: String;
begin
  if (Self = nil) then Exit('');
  Result := FName;
end;

[norwegen60]

Zitat von Blup:

Ja, bei meinem Beispiel liefert Analyse.Methode niemals nil zurück. Sollte FMethode = nil sein, wird das NullObject zurückgegeben. Das erledigt der Getter.

Ja klar. NullObject hat mich auf NIL geleitet aber du machst ja ein

Delphi-Quellcode:

class function TMethode.CreateNullObject: TMethode;
begin
  Result := TMethode.Create;
end;

Zitat von Uwe Raabe:

Ich will auch noch meinen Senf dazu geben [/DELPHI]

Damit müsste ich aber jedem Property einen "smarten Getter" verpassen und das wollte ich vermeiden

Vielen Dank
Gerd

[himitsu]

IfThen ist zwar eine Inline-Funktion und da "könnte" der Compiler das theoretisch so optimieren, dass nur der jeweilige Parameter erst später aufgelöst wird, aber das tut der leider nicht.