Fonctionnalités C # ou .Net à couper en supposant qu'aucune compatibilité descendante n'est nécessaire? [fermé]

Tout produit ou framework évolue. Il est principalement fait pour répondre aux besoins de ses utilisateurs, tirer parti de nouvelles puissances informatiques et simplement les améliorer. Parfois, l'objectif de conception principal change également avec le produit. Le framework C # ou .net ne fait pas exception. Comme nous le voyons, la 4ème version actuelle est très différente de la première. Mais la chose vient comme une barricade à cette compatibilité avec l'évolution vers l'arrière.

Dans la plupart des frameworks / produits, certaines fonctionnalités auraient été supprimées s'il n'était pas nécessaire de prendre en charge la compatibilité descendante. Selon vous, quelles sont ces fonctionnalités dans C # /. Net?

Veuillez mentionner une fonctionnalité par réponse.

Méthodes anonymes . Je pense que tout le monde convient que la syntaxe de méthode anonyme choisie pour C # 2.0 est volumineuse et maladroite par rapport à la syntaxe lambda que nous avons ajoutée à C # 3.0. Il est profondément regrettable d'avoir deux syntaxes presque identiques pour faire la même chose.

Je me débarrasserais des collections non génériques. Ils sont une abomination ... et il y a trop de cas où j'utilise linq et je dois faire quelque chose comme

var customObjects = container.CustomObjects.Cast<CustomObject>();

Chaque fois que je dois faire ça, une petite partie de mon âme meurt.

vide en tant que type . Pourquoi diable est "nul" un type? Il n'a pas d'instances, il n'a pas de valeurs, vous ne pouvez pas l'utiliser comme argument de type générique, type de paramètre formel, type local, type de champ ou type de propriété. Il n'a aucune signification en tant que type; c'est plutôt un fait sur l' effet d'un appel de méthode sur la pile de la machine virtuelle. Mais la machine virtuelle n'est que cela: une machine virtuelle. La vraie machine mettra la valeur retournée dans un registre (généralement EAX sur x86) et n'affectera pas du tout la pile! Le vide en tant que type n'est qu'une mauvaise idée tout autour.

Pire: lorsqu'il est utilisé dans un type pointeur, car void*il signifie quelque chose de complètement différent de ce qu'il signifie lorsqu'il est utilisé comme type de retour. Maintenant, cela signifie "un pointeur vers un emplacement de stockage de type inconnu", ce qui n'a rien à voir avec sa signification en tant que "méthode qui ne renvoie aucune valeur".

Nous pouvons remplacer void*comme type de pointeur par IntPtr. (Et void**avec IntPtr*et ainsi de suite.) Nous pouvons remplacer void comme type de retour par "Unit", un type qui a une seule valeur, à savoir null. Une implémentation du CLR pourrait alors décider qu'un appel de fonction de type unitaire pourrait optimiser son utilisation des registres ou des piles de manière appropriée, sachant que le zéro qui est "renvoyé" peut être ignoré en toute sécurité.

Dans un tel monde , vous ne avez plus besoin de séparer Func<A, R>et les Action<T>délégués. Action<T>est juste Func<T, Unit>.

L'instruction vide; . Sujette aux erreurs, presque toujours une faute de frappe, et ne vous donne aucun sens supplémentaire qui n'est pas déjà exprimé par {}.

Covariance dangereuse sur des tableaux de type référence . Avec la covariance typesafe activée IEnumerable<T>, au moins une partie du besoin de covariance de tableau a disparu. (Si nous avions une interface de liste en lecture seule covariante, nous n'en aurions pas du tout besoin.)

L'opérateur unaire plus . Opérateur le moins utile de tous les temps. Si nous n'avions pas à le garder pour la compatibilité ascendante, je le retirerais en un clin d'œil. Qui utilise cette chose, n'importe qui?

(Précision: l'opérateur unaire plus +xn'est pas l'opérateur pré-incrémenté ++x, ni l'opérateur post-incrémenté x++ni l'opérateur d'addition binaire x+y.)

Par défaut des littéraux numériques double

Pour la plupart des applications d' entreprise , decimalc'est plus approprié de toute façon ... ou peut-être qu'il serait préférable de simplement supprimer l'idée d'un défaut et de forcer le développeur à faire le choix.

(Ce « supprimer le défaut » serait approprié pour d'autres choses aussi. Par exemple, j'ai renoncé à essayer de convaincre tout le monde que les classes doivent être scellés par défaut, mais je pense qu'il est plus facile de persuader les gens qu'ils devraient penser au sujet si leur nouvelle classe doit être scellée ou non, et le rendre explicite.)

C'est plus une ligne directrice qu'une fonctionnalité, mais je pense que c'est important parce que c'est déjà trop ancré dans l'esprit des gens comme la meilleure solution canonique:

Le modèle officiel à mettre en œuvre IDisposable.

C'est lourd et il y a de meilleures façons .

Je sais qu'il y a de grandes différences entre les différentes classes de temporisation. Mais ne pourrions-nous pas nous débarrasser d'un ou deux d'entre eux, de toute façon?

Méthodes et types de Arrayet List<T>qui sont devenus obsolètes avec Linq, par exemple:

• Array.TrueForAll peut être remplacé par Enumerable.All
• Array.FindAll peut être remplacé par Enumerable.Where
• List<T>.ConvertAll peut être remplacé par Enumerable.Select
• Predicate<T> peut être remplacé par Func<T, bool>
• Converter<T,R> peut être remplacé par Func<T, R>
• IComparer<T> devrait vraiment être un délégué Func<T, T, int>

Délégués non génériques Comme les collections non génériques, les délégués non génériques sont inutiles maintenant que nous avons les séries Func et Action. Et j'aurais coupé les variantes à trois paramètres. Si vous avez plus de trois paramètres, créez une structure et utilisez-la comme paramètre unique. Déclarer un délégué spécifique pour la gestion des événements n'est pas très SEC.

Services Web asmx

Je pense qu'ils sont assez obsolètes avec WCF de nos jours.

Winforms
Ce serait bien de ne pas avoir à naviguer entre deux plates-formes de bureau. WPF est où les choses vont, donc c'est frustrant d'avoir une redondance complète au niveau de la plate-forme.