Über den Umgang mit vielen optionalen Parametern

[Khabarakh]

Zitat von Meflin:

Allerdings ist das auch noch blöd, wegen der zwingend nötigen params-Variable. Die will man ja möglichst auch noch loswerden.

Generics machen's möglich... sogar, wenn man sie direkt gar nicht einsetzt .
foo(Default(TParams).paramA(1).paramF(120)) Viel schöner wäre natürlich, wenn sie mal ein wenig bei Prism plündern würden .
Foo(new Params(A = 1, F = 120)); Und für etwas ältere Versionen: Wie wäre es mit einem einfachen
foo(TParams.GetDefault.paramA(1)...

Zitat von Meflin:

Zitat von Neutral General:

function foo(a: Integer; b: Integer = 0; c: Integer = 0): z;

Und wenn ich jetzt c angeben will, b aber nicht?

Deswegen setzen übrigens viele neuere Sprachen auf optionale und benannte Parameter .

Code:

foo(1, c: 2);

Zitat von himitsu:

oder gleich die Funktion in eine eigene Klasse verfrachten und dann die Parameter extra behandeln (also Funktion ohne direkte Parameter).

Schenkt man Microsofts Framework Design Guidelines Glauben, stellt das die Otto-Normalentwickler-freundlichste Lösung dar - "Component-Oriented Design" bzw. "Create-Set-Call Pattern". Für den Implementeur zwar manchmal etwas mehr Arbeit, aber mit solchen APIs scheinen Leute am besten klar zu kommen, wenn sie mit Code Insight darin herumstochern. Eine beiliegende Hilfe ist schließlich höchstens etwas fürs stille Örtchen ;P .

[Meflin]

Zitat von Khabarakh:

Und für etwas ältere Versionen: Wie wäre es mit einem einfachen
foo(TParams.GetDefault.paramA(1)...

Das wirds jetzt wohl werden Da komme ich tatsächlich ohne Überladung aus und das ganze verwendet sich wunderbarst flexibel (und auch die Einführung neuer Parameter ist kein Problem)

Zitat von Khabarakh:

Schenkt man Microsofts Framework Design Guidelines Glauben, stellt das die Otto-Normalentwickler-freundlichste Lösung dar - "Component-Oriented Design" bzw. "Create-Set-Call Pattern". Für den Implementeur zwar manchmal etwas mehr Arbeit, aber mit solchen APIs scheinen Leute am besten klar zu kommen, wenn sie mit Code Insight darin herumstochern. Eine beiliegende Hilfe ist schließlich höchstens etwas fürs stille Örtchen ;P .

Hm. Create-Set-Call kann man ja trotzdem noch machen. Es geht ja weiterhin

Delphi-Quellcode:

var
  params: TParams;
begin
  params := TParams.Create;
  params.a := foo;
  params.b := bar;
  foo(params);
  // gleichbedeutend mit
  foo(TParams.getDefault.setA(foo).setB(bar));
end;

Aber ich bin mir nicht sicher ob das gemeint war

[alzaimar]

Zitat von Meflin:

  foo(TParams.getDefault.setA(foo).setB(bar));

Geht es nicht auch darum, den Code irgendwie lesbar zu gestalten? Das ist doch grauslig, was Du da anstellst. Sieht zwar 'pfiffig' aus, aber lesbar geht anders.

Ich frage mich auch, wie eine Funktion aussehen soll, die einerseits eine Latte von Parametern akzeptiert, von denen alle optional sind, und andererseits so einfach gestrickt ist, das man sie nicht in mehrere Funktionen aufbrechen kann. Aber gut, vielleicht ist es auch nur eine Design- bzw. 'Best practice' Frage.

[himitsu]

Zitat:

Allerdings ist das auch noch blöd, wegen der zwingend nötigen params-Variable. Die will man ja möglichst auch noch loswerden.

Du kannst einem Record auch eine statische Class-Funktion, bzw. einen Constuctor verpassen.

[add]

Delphi-Quellcode:

type
  TParams = record
    //class function Create: TParams; static;
    constructor Create;
    function Default: TParams;
    function paramA(i: Integer): TParams;
    function paramB(i: Integer): TParams;
    function ParamList: TParams;
  private
    paramAValue: Integer;
    paramBValue: Integer;
  end;

constructor TParams.Create;
begin
  Default;
end;

function TParams.Default: TParams;
begin
  Finalize(Self);
  FillChar(@Self, SizeOf(Self), 0);
  Result := Self;
end;

function TParams.paramA(i: Integer): TParams;
begin
  paramAValue := i;
  Result := Self;
end;

function TParams.paramB(i: Integer): TParams;
begin
  paramBValue := i;
  Result := Self;
end;

function TParams.ParamList: TParams;
begin
  Result := Self;
end;

Oder das Ganze als Interface.
Als Interface wäre es Speichersparender.
Also Objekt ginge zwar auch, aber da darf man dann das Freigeben nicht vergessen, welches bei einigen Aufrufvarianten unmöglich/schwer zu realisieren ist.

Delphi-Quellcode:

foo(TParams.Create.paramA(1).paramB(9));

var Params: TParams;
Params.Default;  // oder Params := TParams.Create;
Params.paramA(1);
Params.paramB(9);
foo(Params);

with TParams.Create do begin
  paramA(1);
  paramB(9);
  foo(ParamList);
end;

with TParams.Create do begin
  paramA(1);
  //foo(ParamList.paramB(9));
  foo(paramB(9));
end;

[Meflin]

Zitat von alzaimar:

Das ist doch grauslig, was Du da anstellst. Sieht zwar 'pfiffig' aus, aber lesbar geht anders.

Welcher Teil genau? Schonmal LINQ benutzt? Schonmal jQuery benutzt? So unüblich ist diese Schreibweise nun auch wieder nicht... (außer der getDefault-Teil. Der ist unschön. Lässt sich aber vermutlich nicht verweiden...). Da gehts ja auch so:

Code:

result := list.select(foo).orderBy(bar).thenBy(bar2).intersect(wuppdi);

und nu?

Zitat:

Ich frage mich auch, wie eine Funktion aussehen soll, die einerseits eine Latte von Parametern akzeptiert, von denen alle optional sind, und andererseits so einfach gestrickt ist, das man sie nicht in mehrere Funktionen aufbrechen kann. Aber gut, vielleicht ist es auch nur eine Design- bzw. 'Best practice' Frage.

Stelle dir eine Funktion vor. Man kann eine Sortierung spezifizieren (enum), ein Offset, ein Limit (jeweils int), einen string und zwei Bools (Verhaltensbeeinflussung). Alle diese Parameter sind optional. Zwingend dazu kommt dann noch eine Id (Int). Im Ergebnis der Funktion kommen alle Parameter vor, auch die nicht verwendeten (da nicht spezifiziert sowieso in jedem Fall gleich default bedeutet und es mehr aufwand wäre, auch noch verschiedene Queries zu generieren wenn dies garnicht nötig wäre). Achso, und auf neue Parameter muss man natürlich auch stets vorbereitet sein.

Your try.

Zitat:

Also Objekt ginge zwar auch, aber da darf man dann das Freigeben nicht vergessen, welches bei einigen Aufrufvarianten unmöglich/schwer zu realisieren ist.

Lokale Variablen sollten aber doch (egal ob nun "anonym" oder nicht) am Funktionsende ohne zutun weggeräumt werden. Oder nicht

[BUG]

Zitat von Meflin:

Lokale Variablen sollten aber doch (egal ob nun "anonym" oder nicht) am Funktionsende ohne zutun weggeräumt werden. Oder nicht

Delphi (win32) hat keinen Garbage Collector, egal wie sehr du ihn dir wünschst
Taucht ja in einigen deiner Posts auf.

Das heißt alle Objekte (abgesehen von welchen in Interface-Typen), die du erstellst, musst du auch selbst wegräumen.

[Meflin]

Zitat von BUG:

Delphi (win32) hat keinen Garbage Collector, egal wie sehr du ihn dir wünschst

Aber... Es... Ich... http://www.fnse.de/S01/0R2.gif

Das hat man nun davon. Hat man die bessere Welt erstmal kennengelernt, gefällts einem in der anderen nicht mehr

[himitsu]

Interfaces und Records, sowie dyn. Arrays und String räumen sich selber auf, bzw. Delphi macht dieses für einen.

Pointer und Objekte muß man manuell aufräumen


seit D2006: mit einem Record geht es einfach
und mit Interfaces isses Ergebnis "schöner"

[Khabarakh]

Zitat von Meflin:

Create-Set-Call kann man ja trotzdem noch machen. [...]
Aber ich bin mir nicht sicher ob das gemeint war

Es geht wirklich nur um den Unterschied, die Funktion dann direkt TParams zuzuordnen (und für den Reocrd oder dann wahrscheinlich Klasse noch vielleicht nen etwas hübscheren Namen zu finden ). Soll so anscheinend einfacher bedienbar sein, aber wir fallen wahrscheinlich gar nicht mehr unter die Zielgruppe .

Zitat von himitsu:

Du kannst einem Record auch eine statische Class-Funktion, bzw. einen Constuctor verpassen.

Parameterlose Konstruktoren gibt es bei Records (zurecht) nicht.

Zitat von alzaimar:

Geht es nicht auch darum, den Code irgendwie lesbar zu gestalten? Das ist doch grauslig, was Du da anstellst. Sieht zwar 'pfiffig' aus, aber lesbar geht anders.

Wenn es ums Initialisieren von Objekten geht, ist mir Fluent Syntax auch nicht geheuer - deswegen die Bitte um Prisms Object Initializers . Sowas wie

Code:

new Bar()
.AddItem(1)
.AddItem(2)
.WithOptions()
    .SetCached(true)
.EndOptions()

ist mir dann doch etwas zu "tricky" (und vor allem zu blöd zum Implementieren). Dann lieber

Code:

new Bar {
    Items = { 1, 2 },
    Options = new Options(cached: true)
}

Zwischen new TParams() und TParams.GetDefault sehe ich allerdings keinen großartigen Unterschied . In Ruby könnten wir es "gimme!" nennen .

[himitsu]

Zitat von Khabarakh:

Parameterlose Konstruktoren gibt es bei Records (zurecht) nicht.

OK, aber die parameterlose Static-Function sollte dennoch gehn.

Aber wieso eigentlich immer "zurecht"?

Statt der TParams.GetDefault-Methode könnte man notfalls auch noch eine CreateParams-Funktion erstellen

Delphi-Quellcode:

type
  TParams = record
    class function Create: TParams; static;
    function Default: TParams;
    function paramA(i: Integer): TParams;
    function paramB(i: Integer): TParams;
    function ParamList: TParams;
  private
    paramAValue: Integer;
    paramBValue: Integer;
  end;

function CreateParams: TParams;





function CreateParams: TParams;
begin
  Result.Default;
end;

class function TParams.Create: TParams;
begin
  Result.Default;
end;

function TParams.Default: TParams;
begin
  Finalize(Self);
  FillChar(@Self, SizeOf(Self), 0);
  Result := Self;
end;

function TParams.paramA(i: Integer): TParams;
begin
  paramAValue := i;
  Result := Self;
end;

function TParams.paramB(i: Integer): TParams;
begin
  paramBValue := i;
  Result := Self;
end;

function TParams.ParamList: TParams;
begin
  Result := Self;
end;