Posso detectar se recebi um novo objeto como parâmetro?

Versão curta

Para aqueles que não têm tempo para ler o meu raciocínio para esta questão abaixo:

Existe alguma maneira de impor uma política de "apenas novos objetos" ou "apenas objetos existentes" para os parâmetros de um método?

Versão longa

Existem muitos métodos que tomam objetos como parâmetros, e não importa se o método tem o objeto "all to itself" ou não. Por exemplo:

var people = new List<Person>();

Person bob = new Person("Bob");

people.Add(bob);
people.Add(new Person("Larry"));

Aqui oList<Person>.Add método tomou um "existente"Person (Bob), bem como um "novo"Person (Larry) e a lista contém os dois itens. Bob pode ser acessado comobob oupeople[0]. Larry pode ser acessado comopeople[1] e, se desejado, armazenado em cache e acessado comolarry (ou qualquer outro) depois disso.

OK, tudo bem. Mas às vezes um método realmentenão deveria ser passado um novo objeto. Considere por exemplo,Array.Sort<T>. O seguinte não faz muito sentido:

Array.Sort<int>(new int[] {5, 6, 3, 7, 2, 1});

Todo o código acima é pegar uma nova matriz, classificá-la e depois esquecê-la (como sua contagem de referência chega a zero depoisArray.Sort<int> Exits e o array ordenado serão, portanto, coletados como lixo, se não me engano). assimArray.Sort<T> espera um array "existente" como seu argumento.

Existem outros métodos concebíveis que podemEspero "novos" objetos (embora eu geralmente pensasse que ter essa expectativa seria um erro de projeto). Um exemplo imperfeito seria este:

DataTable firstTable = myDataSet.Tables["FirstTable"];
DataTable secondTable = myDataSet.Tables["SecondTable"];

firstTable.Rows.Add(secondTable.Rows[0]);

Como eu disse, isso não é um ótimo exemplo, já queDataRowCollection.Add não espera realmente umNovo DataRow, exatamente; mas issofaz espere umDataRow que ainda não pertence a umDataTable. Então a última linha no código acima não funcionará; precisa ser:

firstTable.ImportRow(secondTable.Rows[0]);

Enfim, isso é muita configuração para a minha pergunta, que é:Existe alguma maneira de aplicar uma política de "apenas novos objetos" ou "apenas objetos existentes" para os parâmetros de um método, ou na sua definição (talvez por alguns atributos personalizados dos quais não estou ciente) ou dentro do próprio método (talvez por reflexão, embora eu provavelmente fuja disso mesmo que esteja disponível)?

Se não, quaisquer ideias interessantes sobre como possivelmente conseguir isso seriam mais do que bem-vindas. Por exemplo, suponho que se houvesse alguma maneira de obter a contagem de referência do GC para um determinado objeto, você poderia dizer imediatamente no início de um método se você recebeu um novo objeto ou não (assumindo que você está lidando com tipos de referência , claro - que é o único cenário para o qual esta questão é relevante de qualquer maneira).

EDITAR:

A versão mais longa fica mais longa.

Tudo bem, suponha que eu tenha algum método que eu queira aceitar opcionalmenteTextWriter para produzir seu progresso ou o que você tem:

static void TryDoSomething(TextWriter output) {
    // do something...
    if (output != null)
        output.WriteLine("Did something...");

    // do something else...
    if (output != null)
        output.WriteLine("Did something else...");

    // etc. etc.

    if (output != null)
        // do I call output.Close() or not?
}

static void TryDoSomething() {
    TryDoSomething(null);
}

Agora, vamos considerar duas maneiras diferentes pelas quais eu poderia chamar esse método:

string path = GetFilePath();
using (StreamWriter writer = new StreamWriter(path)) {
    TryDoSomething(writer);

    // do more things with writer
}

OU:

TryDoSomething(new StreamWriter(path));

Hmm ... parece que isso representa um problema, não é? Eu construí umStreamWriter, que implementaIDisposable, masTryDoSomething não vai presumir saber se tem acesso exclusivo ao seuoutput argumento ou não. Assim, o objeto é descartado prematuramente (no primeiro caso) ou não é descartado (no segundo caso).

Não estou dizendo que isso seria um ótimo design, necessariamente. Talvez Josh Stodola esteja certo e isso é apenas uma má ideia desde o início. De qualquer forma, eu fiz a pergunta principalmente porque eu estava apenas curioso para saber sepossível. Parece que a resposta é: não realmente.

questionAnswers(9)

yourAnswerToTheQuestion