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
.