Perché System.String non include un costruttore che accetta un oggetto IEnumerablechar?

0

Perché System.String non include un costruttore in grado di prendere un IEnumerable<char> ?

Il comportamento previsto sarebbe:

var foo = "hello";
var bar = new string(foo.Select(x => x));

Comportamento effettivo:

Cannot convert from 'System.Collections.Generic.IEnumerable<char>' to 'char*'

Se non c'è una ragione ovvia, penso che potrebbe essere una bella richiesta di pull.

fonte: String.cs StringNative.cpp

    
posta aloisdg 06.07.2016 - 22:17
fonte

3 risposte

5

Poiché esiste un sovraccarico del costruttore che accetta un array di caratteri, questo dovrebbe funzionare:

var bar = new string(foo.Select(x => x).ToArray());

Che praticamente elimina la necessità di un altro sovraccarico del costruttore, in quanto il sovraccarico proposto dovrebbe essenzialmente fare la stessa cosa.

Eric Lippert spesso discute il motivo per cui alcune funzionalità non lo fanno nel .NET Framework o nel linguaggio C #. Dice:

The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature. All six of those things are necessary to make a feature happen. All of them cost huge amounts of time, effort and money.

In altre parole, ogni funzione deve avere vantaggi che superano tali costi e il team .NET ha deciso in questa istanza che il costruttore extra non ne valeva la pena.

Ulteriori letture
Il modo migliore per convertire IEnumerable in stringa?

    
risposta data 06.07.2016 - 22:32
fonte
2

Questo costruttore prende come input una serie di caratteri. Per il tuo caso d'uso, puoi semplicemente:

var bar = new string(foo.Select(x => x).ToArray());

Se si desidera una spiegazione logica, si potrebbe dire che il comportamento di caricamento lento dell'IEnumerable non offre alcun vantaggio aggiuntivo in questo caso, poiché è comunque necessario leggere l'intera cosa per creare la stringa. Sia che tu lo converti in un array prima di passarlo, come fa il mio esempio, o lo passi un IEnumerable per il costruttore da convertire, le operazioni e le prestazioni dovrebbero essere quasi le stesse.

    
risposta data 06.07.2016 - 22:38
fonte
1

Da un lato ci aspettiamo praticità, dall'altro i rigorosi principi OOP applicati. Se si implementano troppi overload utili, si implementerà presto un convertitore di tipo universale in una classe di stringa. E poi qualcos'altro. Suppongo che mantenere le cose in ordine e attenersi e attenersi al principio della responsabilità unica superi il bisogno di maggiore praticità. Come altri hanno sottolineato, non c'è davvero alcun inconveniente nell'usare ToArray sull'argomento. Si tratta di mettere responsabilità a cui appartengono.

    
risposta data 06.07.2016 - 22:56
fonte

Leggi altre domande sui tag