Parameter C # .Net 4.0 Benannte und Standard

Question

Welchen Wert denken Sie Namen und Standardparameter werden in C # .Net 4.0 hinzufügen?

Was wäre eine gute Verwendung für diese sein (das ist mit Überlastung und Überschreiben nicht bereits erreicht)?

Answer 1

Es kann Konstrukteuren einfacher machen, vor allem für unveränderliche Typen (die zum Einfädeln von Bedeutung sind) - siehe hier für eine Diskussion . Nicht so schön wie es sollte sein vielleicht, aber schöner als viele Überlastungen haben. Sie können natürlich nicht Objektinitialisierer mit unveränderlichen Objekten, so den üblichen Verwendung:

new Foo {Id = 25, Name = "Fred"}

nicht verfügbar ist; Ich werde zufrieden geben:

new Foo (Id: 25, Name: "Fred")

Dies ist auf die allgemeine Idee der Vereinfachung Überlastungen verlängert werden, aber in die meisten Fälle Ich würde es vorziehen, Überlastungen, die die Rechts Kombinationen werben. Konstruktoren sind ein bisschen anders, IMO, da Sie nur (in der Regel), die den Ausgangszustand sind.

Die COM-Seite der Dinge ist auch wichtig, eine Menge Leute, aber ich einfach nicht viel COM-Interop verwenden -. So ist dies nicht wie wichtig für mich

---

Bearbeiten re Kommentare; warum haben sie nicht benutzen Sie einfach die gleiche Syntax, die Verwendung Attribute? Ganz einfach - es kann mit anderen Mitgliedern / Variablen nicht eindeutig sein (die mit Attributen kein Thema ist); nehmen Sie das Beispiel:

[XmlElement("foo", Namespace = "bar")]

, die verwendet einen regulären Parameter (zum Ctor, "foo"), und eine mit dem Namen Zuordnung. So nehmen wir verwenden diese für die regelmäßige benannten Argumente:

SomeMethod("foo", SecondArg = "bar");

(der auch ein Konstruktor sein könnte, ich habe ein Verfahren zur Einfachheit verwendet)

Nun ... was ist, wenn wir eine Variable oder eine Eigenschaft namens SecondArg? Dies würde zwischen der Verwendung von SecondArg als benannte Argument nicht eindeutig sein, um SomeMethod und "bar" Zuordnung SecondArg und "bar" als reguläres Argument übergeben .

Zur Veranschaulichung ist diese legal in C # 3.0:

    static void SomeMethod(string x, string y) { }
    static void Main()
    {
        string SecondArg;
        SomeMethod("foo", SecondArg = "bar");
    }

Natürlich könnte SecondArg sein eine Eigenschaft, ein Feld, varialble, etc ...

Die alternative Syntax nicht diese Mehrdeutigkeit hat.

---

Bearbeiten - dieser Abschnitt durch 280Z28: Sorry für das Hinzufügen dieser hier, aber es ist nicht wirklich eine einzigartige Antwort und es ist zu lang für die Kommentare und enthält Code. Sie deutete an, die Mehrdeutigkeit aber Ihr Beispiel hat den entscheidenden Fall nicht markieren. Ich denke, das Beispiel, das Sie gab etwas weist darauf hin, die verwirrend sein könnte, aber die erforderliche {} um Objektinitialisierer verhindert eine darunter liegende syntaktische Mehrdeutigkeit. Meine Erklärung für den folgenden Code wird als mehrzeiligen Block Kommentar eingebettet.

[AttributeUsage(AttributeTargets.Class)]
public sealed class SomeAttribute : Attribute
{
    public SomeAttribute() { }

    public SomeAttribute(int SomeVariable)
    {
        this.SomeVariable = SomeVariable;
    }

    public int SomeVariable
    {
        get;
        set;
    }
}

/* Here's the true ambiguity: When you add an attribute, and only in this case
 * there would be no way without a new syntax to use named arguments with attributes.
 * This is a particular problem because attributes are a prime candidate for
 * constructor simplification for immutable data types.
 */

// This calls the constructor with 1 arg
[Some(SomeVariable: 3)]
// This calls the constructor with 0 args, followed by setting a property
[Some(SomeVariable = 3)]
public class SomeClass
{
}

---

Answer 2

Es wird das Problem der Bereitstellung eine anständige API ausweichen hilft mit Office-Anwendungen zu arbeiten! :)

Einige Teile des Office-API sind in Ordnung, aber es gibt Grenzfälle, die eindeutig für von einer Sprache mit optionalen / benannte Parametern konzipiert wurden. Also, warum C #, sie haben hat.

Answer 3

Optionale Parameter vermeiden auch das Problem, wo Klassen Dutzende von Methoden zur Verfügung stellen, die akzeptiert nur Variationen der Argumente sind.

Betrachten Sie die Exception-Klasse. Statt eines Konstruktors mit optionalen Argumenten, hat es vier Konstruktoren für jede Kombination von ‚hat Nachricht‘ und "hat innere Ausnahme. Das ist in Ordnung, aber jetzt überlegen, was passiert, wenn Sie einen Nullwert zu einem Konstruktor gibt einen innerexception zu nehmen? Ist es genau wie der Konstruktor handeln ohne innerexception Parameter, sortof wie der Konstruktor ohne innerexception Parameter, oder wirft es eine NULL-Verweis Ausnahme?

Ein einzelner Konstruktor mit zwei optionalen Parametern hätte es deutlicher gemacht, dass ein Null innerexception vorbei entspricht es überhaupt nicht darunter. Ein perfekter Ort für Standardargumente.

Vergessen Sie auch nicht, dass nun jede abgeleitete Exception-Klasse auch 4 Konstrukteurs enthalten hat, die ein sinnloser Streit ist.

Answer 4

Es wird machen COM-Interop viel einfacher.

Bis C # 4 VB.Net war eine viel bessere Sprache für Interop. Ohne Vorgaben haben Sie massive Listen der Dummy-ref Parameter in C #.

Answer 5

Brevity von Code ist die offensichtlichste, die in den Sinn kommt. Warum mehr Überlastungen definieren, wenn Sie eine Funktion definieren können. Auch, obwohl, wenn Sie zwei identisch eingegeben Parameter haben, ist es nicht immer möglich, den vollen Satz von Überlastungen zu konstruieren Sie benötigen.

Answer 6

Auch bedeutet dies nicht kompilieren:

[AttributeUsage(AttributeTargets.Property, Inherited = false, AllowMultiple = true)]
sealed class MyAttribute : Attribute
{
    public MyAttribute(object a = null)
    {

    }
}


class Test
{
    [My] // [My(a: "asd")]
    int prop1 { get; set; }
}

, während dies tut:

[AttributeUsage(AttributeTargets.Property, Inherited = false, AllowMultiple = true)]
sealed class MyAttribute : Attribute
{
    public MyAttribute()
    {

    }

    public object a { get; set; }
}

class Test
{
    [My] // [My(a=null)]
    int prop1 { get; set; }
}