Perché il nome di un membro di una classe non può essere uguale a una delle sue classi nidificate?

Question

O perché è la seguente impossibile:

class Material 
{ 
    class Keys 
    { 
     ... 
    } 

    Material.Keys Keys { get; set; } // Illegal 
} 

non vedo ogni possibile ambiguità. Quando si accede per istanza, restituire la proprietà. Quando accedi in modo statico, restituisci la classe. O mi sta sfuggendo qualcosa?

Non sto chiedendo una "correzione" (so che potrei chiamarlo in modo diverso, come MaterialKeys o simili), ma più di una ragione tecnica dietro questo limite.

Answer 1

Ma Immagina di avere questo:

class Material 
{ 
    class Keys 
    { 
     ... 
    } 

    static Material.Keys Keys = new Keys(); 
} 

Ora entrambi sono a portata "statico". Ora, il compilatore può disambiguare in tutti i casi? In caso contrario, questo non può essere consentito.

Suppongo che sia possibile che la disambiguazione funzioni per campi/proprietà/metodi statici e non per membri di esempio. O viceversa.In tal caso, vorresti che le specifiche della lingua consentissero a un membro di un'istanza di avere lo stesso nome di una classe interna, ma di non utilizzarlo per la statica? Sarebbe solo confuso.

Ma poi, avere un membro che corrisponde al nome di una classe interna è comunque piuttosto confuso.

Answer 2

Poiché la classe nidificata Keys è un membro di Material come la proprietà Keys. Hai due membri chiamati Keys.

Allo stesso modo non si possono avere due proprietà chiamato la stessa cosa:

public class Bar 
{ 
    private bool Foo { get; set; } 
    private string Foo { get; set; } 
} 

Quando si accede Foo quale stai tentando di accedere?

public class Material : Keys 
{ 

    private Keys K { get; set; } 
} 

public class Keys 
{ 

} 

Funziona bene, ma probabilmente non è quello che cerchi.

Answer 3

Lei ha detto,

quando vi si accede da esempio, restituire la proprietà. Quando accedi in modo statico, restituisci la classe.

Ma cosa succede se dici solo Keys da qualche parte dentro Material? Si tratta di un accesso statico o di istanza? Si riferisce alla proprietà Keys o al tipo nidificato Keys? In realtà è ambiguo.

Per esempio,

class Material 
{ 
    class Keys 
    { 
     public static int Length; 
    } 

    string Keys { get; set; } 

    public void Process() 
    { 
     // Does this refer to string.Length (via property Keys) 
     // or Material.Keys.Length? It actually refers to both. 
     Console.WriteLine(Keys.Length); 
    } 
} 

Come sottolineato nei commenti, questa non è tutta la storia; ma quasi. È valido per avere una proprietà denominata Color del tipo Color e non c'è nessuno scontro:

public Color Color { get; set; } 

Color.FromName(...) // refers to static method on the type ‘Color’ 
Color.ToString()  // refers to instance method on the property’s value 

Ma questo è facile da risolvere, semplicemente perché le cose nel campo di applicazione corrente conquistare le cose in ambiti più esterni:

public class MyType { public string FromName(string name) { return null; } } 
public MyType Color; 

Color.FromName(...) // unambiguously refers to MyType::FromName(string) 
         // via the property Color 

Non è così semplice nell'esempio: la classe nidificata Keys e la proprietà Keys sono nello stesso ambito (hanno lo stesso tipo di dichiarazione). Come decidi quale dare la priorità? E anche se decidessi di dare una priorità a loro, questo sarebbe utile solo marginalmente perché potresti avere solo due cose con lo stesso nome, e una dovrebbe essere statica e l'altra.

Answer 4

La mia risposta affronta la domanda da una prospettiva leggermente diversa, rispetto alle altre domande. Delle due seguenti dichiarazioni in una specifica di linguaggio C#:

The same identifier may not be used in different definitions within one scope 

e

The same identifier may not be used in different definitions within one scope, unless it is probably impossible for any ambiguity to arise when the identifier is used 

, il primo è molto più semplice.

La semplicità è un obiettivo chiave nella progettazione della lingua, perché i linguaggi più semplici sono più facili da implementare per gli autori di compilatori e interpreti, più semplici da generare e manipolare, più facili da apprendere per i principianti e più facili da comprendere per i programmatori. Quando si considera qualsiasi caratteristica linguistica, la complessità che tale caratteristica aggiunge alla lingua deve essere considerata negativa e deve quindi essere bilanciata da una misura di utilità almeno equivalente. Come hai affermato tu stesso, consentire ciò non aggiungerebbe alcuna funzionalità reale (dato che è così facile da aggirare), quindi non c'era alcun motivo valido per complicare ulteriormente le specifiche di C# includendolo.

Answer 5

"Tutto ciò che non è ambiguo dovrebbe essere legale" NON è assolutamente un principio di progettazione del linguaggio C#. Il linguaggio C# è progettato per essere un linguaggio "di qualità"; cioè, le regole della lingua dovrebbero gettarti in una buca piena di codice chiaramente corretto, e devi lavorare per arrampicarti fuori dalla buca per trasformarlo in codice errato. L'idea che "qualunque cosa non sia ambigua dovrebbe essere legale" funziona nella maggior parte dei casi direttamente contro il concetto di un linguaggio di "fossa di qualità".

Inoltre, la tua idea di dover fornire una giustificazione per non eseguire una funzione è al contrario. Non è necessario per fornire una giustificazione per non facendo una funzione. Piuttosto, le caratteristiche proposte da devono essere giustificate dimostrando che i loro benefici superano i loro enormi costi. Le caratteristiche sono molto costose e abbiamo un budget limitato; dobbiamo solo fare le migliori caratteristiche per offrire i loro benefici ai nostri clienti.

La funzionalità proposta consente la facile produzione di codice fragile e confuso; aiuta a trasformare il C# in un linguaggio "buca della disperazione" invece di un linguaggio "buca della qualità". Le caratteristiche che aggiungono fragilità e confusione alla lingua devono aggiungere un enorme vantaggio per compensare tali costi. Qual è secondo te l'enorme vantaggio che questa funzione aggiunge al linguaggio che giustifica i suoi costi?

Se la risposta è "non c'è tale vantaggio", ora sai perché la lingua non ha questa caratteristica: perché peggiora la lingua, netta.

Se c'è un vantaggio, sono felice di considerare i suoi meriti per ipotetiche versioni future della lingua.