C # .Net 4.0 Nomeado e padrão Parâmetros

Question

Qual o valor que você acha nomeados e parâmetros padrão irá adicionar em C # .Net 4.0?

O que seria um bom uso para estes (que ainda não foi alcançado com a sobrecarga e substituindo)?

Answer 1

Pode fazer construtores mais simples, especialmente para tipos imutáveis ??(que são importantes para rosqueamento) - veja aqui para uma discussão completa . Não tão bom como ele deve ser, talvez, mas mais agradável do que ter um monte de sobrecargas. Você, obviamente, não pode usar inicializadores de objeto com objetos imutáveis, de modo que o habitual:

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

não está disponível; Eu vou resolver para:

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

Esta pode ser estendido para a idéia geral de sobrecargas simplificadoras, mas em mais casos eu prefiro sobrecargas que anunciam as combinações legais. Construtores são um pouco diferentes, IMO, uma vez que são apenas (tipicamente) definir o estado inicial.

O lado COM das coisas também é importante para um monte de gente, mas eu simplesmente não usar muito interoperabilidade COM -. Modo que este não é como importante para mim

---

Editar re comentários; por que eles não apenas usar a mesma sintaxe que atribui uso? Simples - pode ser ambígua com outros membros / variáveis ??(que não é um problema com atributos); tomar o exemplo:

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

que utiliza um parâmetro normal (ao ctor, "foo"), e uma atribuição nomeado. Então, suponha que usar isso para regulares argumentos nomeados:

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

(que também poderia ser um construtor, eu usei um método para simplificar)

Agora ... o que se temos uma variável ou uma propriedade chamada SecondArg? Isso seria ambígua entre usando SecondArg como um argumento nomeado para SomeMethod, e atribuição de "bar" para SecondArg, e passando "bar" como um argumento comum .

Para ilustrar, isso é legal em C # 3.0:

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

Obviamente, SecondArg poderia ser uma propriedade, campo, varialble, etc ...

A sintaxe alternativa não tem essa ambiguidade.

---

Edit - esta seção 280Z28: Desculpe para adicionar este aqui, mas não é realmente uma resposta única e que é demasiado longo para os comentários e inclui código. Você insinuou a ambigüidade, mas o seu exemplo não destacar o caso de decidir. Acho que o exemplo que você deu pontos fora algo que poderia ser confuso, mas a {} necessário em torno de inicializadores de objeto impede uma ambigüidade sintática subjacente. Minha explicação para o seguinte código é incorporado como o comentário de bloco multi-line.

[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

Ela vai ajudar a evitar o problema de fornecer uma API decente para trabalhar com aplicativos do Office! :)

Algumas partes do Office API estão bem, mas há casos de borda que foram claramente projetados para o uso de uma linguagem com opcionais / parâmetros nomeados. Então é por isso C # tem que tê-los.

Answer 3

Parâmetros opcionais também evitar o problema onde as aulas fornecem dezenas de métodos que são apenas variações sobre os argumentos aceites.

Considere a classe de exceção. Em vez de um construtor com argumentos opcionais, tem quatro construtores para cada combinação de 'tem a mensagem' e 'tem exceção interna'. Tudo bem, mas agora considerar o que acontece se você fornecer um valor nulo para um construtor tomar um innerException? Será que agir exatamente como o construtor com com nenhum parâmetro innerException, sortof como o construtor com nenhum parâmetro innerException, ou ele lançar uma exceção de referência nula?

Um único construtor com 2 parâmetros opcionais teria tornado mais evidente que a passagem de um innerException nulo foi equivalente a não incluí-lo em tudo. Um lugar perfeito para argumentos padrão.

Também não se esqueça que agora cada classe de exceção derivada também tem de incluir 4 construtores, o que é um aborrecimento sem sentido.

Answer 4

Ele vai fazer interoperabilidade muito mais fácil.

Até C # 4 VB.Net era uma língua muito melhor para interoperabilidade. Sem padrões você tem listas enormes de ref parâmetros fictícios em C #.

Answer 5

A brevidade do código é a mais óbvia que vem à mente. Por definir várias sobrecargas quando você pode definir uma função. Além disso, porém, se você tem dois parâmetros de forma idêntica digitadas, nem sempre é possível construir o conjunto completo de sobrecargas que você pode precisar.

Answer 6

Além disso, este não compila:

[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; }
}

Enquanto isto faz:

[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; }
}