Zugriff auf Unterklasse absichern

[TiGü]

Zitat:

Zitat von Zacherl (Beitrag 1377914)

Verstehe ich hier etwas falsch und

Delphi-Quellcode:

IfThen

soll nicht den ternären Operator simulieren? Wenn ich richtig liege, würde nämlich nur

Delphi-Quellcode:

Assigned(Analyse.Method)

ausgewertet - was ja vollkommen legitim ist - und dann abhängig vom Ergebnis das erste- oder zweite Argument zurückgegeben.

Leider nicht, es werden alle Funktion für die drei Argumente ausgeführt. Kann man auch schnell hinterherdebuggen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils,
  System.Math;

var
  Res: Integer;

function GiveDecision: Boolean;
begin
  Writeln('GiveDecision');
  Result := Boolean(RandomRange(0, 1));
end;

function GiveFive: Integer;
begin
  Writeln('GiveFive');
  Result := 5;
end;

function GiveFour: Integer;
begin
  Writeln('GiveFour');
  Result := 4;
end;

begin
  try
    Res := IfThen(GiveDecision, GiveFive, GiveFour);
    Writeln('Res: ' + Res.ToString);
    Readln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

end.

[DeddyH]

Da es ja hier um einen String geht, dürfte das IfThen aus StrUtils gemeint sein:

Zitat:

Zitat von StrUtils (Delphi Berlin)

Delphi-Quellcode:

function IfThen(AValue: Boolean; const ATrue: string;
  AFalse: string = ''): string;
begin
  if AValue then
    Result := ATrue
  else
    Result := AFalse;
end;

Das sollte doch gefahrlos anzuwenden sein wie gezeigt.

[edit] Nee, Denkfehler, es wird ja trotzdem darauf zugegriffen. [/edit]

[bra]

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

[DeddyH]

Japp, siehe mein Edit.

[Blup]

Zitat:

Zitat von norwegen60 (Beitrag 1377911)

Zitat:

Zitat von Blup (Beitrag 1377899)

@norweger60
Analyse.Methode liefert üer den Getter nun bei FMethode = nil das Nullobjekt zurück. Der Name ist zwar leer, aber das macht ja bei einem Label auch Sinn. Sollte ein Fehler auftreten, der Schreibzugriffe auf Properties des Nullobjekt zur Folge hat, werden diese ignoriert. So wird der Fehler nicht in andere Programmteile verschleppt.

Analyse.Methode liefert ja auch NIL zurück, wenn ich sie gar nicht belegt habe. Und NIL.Name führt dann zur Exception. Oder überseh ich was?

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

[Wosi]

Zitat:

Zitat von DeddyH (Beitrag 1377917)

Da es ja hier um einen String geht, dürfte das IfThen aus StrUtils gemeint sein:

Zitat:

Zitat von StrUtils (Delphi Berlin)

Delphi-Quellcode:

function IfThen(AValue: Boolean; const ATrue: string;
  AFalse: string = ''): string;
begin
  if AValue then
    Result := ATrue
  else
    Result := AFalse;
end;

Das sollte doch gefahrlos anzuwenden sein wie gezeigt.

[edit] Nee, Denkfehler, es wird ja trotzdem darauf zugegriffen. [/edit]

Um die Auswertung von Analyse.Method.Name nur im Erfolgsfall durchzuführen, müsste man anstelle eines String-Parameters ein TFunc<String> verwenden:

Delphi-Quellcode:

function IfThen(AValue: Boolean; const ATrueFunc: TFunc<String>;
  AFalse: string = ''): string;
begin
  if AValue then
    Result := ATrueFunc()
  else
    Result := AFalse;
end;

Der Aufruf sähe dann so aus:

Delphi-Quellcode:

IfThen(Assigned(Analyse.Method), function: String begin Result := Analyse.Method.Name end);

Und da diese Schreibweise ein wenig aufwendig ist, kann man auch gleich bei

Delphi-Quellcode:

if Assigned(Analyse.Method) then 
  Label1.Caption := Analyse.Method.Name;

bleiben.

[Zacherl]

Zitat:

Zitat von bra (Beitrag 1377918)

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

Achja logisch. Zu viel C programmiert in letzter Zeit 8-)

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:

Delphi-Quellcode:

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 :-D

Man kann dem Property Name in

Delphi-Quellcode:

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:

Zitat von Blup (Beitrag 1377920)

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:

Zitat von Uwe Raabe (Beitrag 1377929)

Ich will auch noch meinen Senf dazu geben :-D[/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.