Discussion :

[miaous]

J'ai un petit problème avec l'implémentation par défaut dans une interface.
C# n'implémente pas l'héritage multiple, car "on ne sait pas quoi faire si une classe hérite de 2 classes qui implémentent la même méthode".

Quid d'une classe qui hérite de 2 Interfaces qui implémentent la même méthode ? On se retrouve avec le même "problème".

Tatayo.

en java, si une classe implémente 2 interface qui definisse la même méthode par défaut. Il faut implémente obligatoirement dans la classe.
Il doit avoir le même cas en c#

[François DORIN]

en java, si une classe implémente 2 interface qui definisse la même méthode par défaut. Il faut implémente obligatoirement dans la classe.
Il doit avoir le même cas en c#

En C#, il est possible d'implémenter un membre d'une interface de manière implicite ou explicite. En cas de présence de deux implémentations, il serait possible d'avoir un code qui compile, mais il serait alors obligatoire de préciser l'interface utilisée lors de l'appel à la méthde, pour savoir quelle version utilisée. Je n'ai pas regardé en détail au niveau de ce cas, donc je ne sais pas si c'est supporté. Mais c'est une possibilité.


Au sujet des références nullables, je ne suis pas contre sur le principe. Cela peut permettre d'éclaircir le code. Par contre, ce que je trouve dommage, c'est que c'est un changement générant une incompatibilité avec le code déjà existant. Un point fort de C# jusqu'à présent était sa compatibilité et sa pérennité (qui en prennent un coup pour le coup).

Si .NET Core 3.0 ainsi que Xamarin, Unity et Mono implémenteront complètement .NET Standard 2.1, .NET Framework 4.8 ne le fera pas.

Cette phrase est trompeuse car sous-entend que .NET Framework 4.8 implémentera partiellement .NET Standard 2.1. Certains ajouts de C#8 ne seront pas supportés par le framework 4.8 car il ne sera pas compatible .NET Standard 2.1. Ce n'est pas une compatibilité "à la carte" où le framework .NET 4.8 implémenterait de manière partielle .NET Standard 2.1. Le framework .NET 4.8 implémentera uniquement .NET Standard 2.0, et comme certaines fonctionnalités de C#8 dépendront de type introduit par la version 2.1, ces fonctionnalités ne seront donc pas présentes.

Ce choix a été fait pour des raisons de compatibilité justement et pour ne pas risquer de casser des programmes existants, car certaines de ces fonctionnalités nécessitent une mise à jour du CLR.

[ijk-ref]

Au sujet des références nullables, je ne suis pas contre sur le principe. Cela peut permettre d'éclaircir le code. Par contre, ce que je trouve dommage, c'est que c'est un changement générant une incompatibilité avec le code déjà existant. Un point fort de C# jusqu'à présent était sa compatibilité et sa pérennité (qui en prennent un coup pour le coup).

Au contraire pour moi c'est une grande force d'accepter de corriger une GROSSE erreur où tellement d'autres seraient rester sur "oui mais on a toujours fait comme ça", "pas besoin de compliquer un truc facile", "ça dérange seulement les mauvais programmeurs"

[Noxen]

L'article ne parle pas des interfaces qui pourront porter une implémentation de base ????!!!!
Pourtant c'est une des features que je préfère !

Exemple (codé sans passer par IDE dsl)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
interface IViewModel : INotifyPropertyChanged
{
 void RaisePropertyChanged(string propertyName)
{
    PropertyChanged?.invoke(propertyName);
}
}

Ça c'est justement un cas où ça me paraîtrait inapproprié. D'un point de vue fonctionnel un IViewModel ne devrait pas permettre à son consommateur de lever lui-même l'événement, après tout seul le ViewModel peut dire si une de ses propriétés à réellement changé sa valeur (puisqu'il pourrait par exemple bloquer l'affectation d'une valeur invalide). Ce genre de méthode n'a ça place que dans la structure interne d'une classe et ne devrait pas être dans une interface. Si on veut factoriser ce code on le ferait dans une classe de base (éventuellement abstract) qui serait héritée par d'autres classes spécifiques. En revanche on pourrait avoir, j'imagine, une méthode GetModelVersion(), qui donnerait des informations sur le modèle de données sous-jacent, et renverrait une valeur par défaut si ce n'est pas géré par une implémentation spécifique.

En outre il me semble que ce mécanisme devait être introduit pour permettre de faire évoluer une interface sans introduire de breaking change auprès des "implémenteurs" (qui autrement ne seraient plus compatibles avec leurs propres consommateurs). Il me semble que l'utiliser pour factoriser du code constitue un peu un détournement de l'intention de départ.

[Pol63]

Quid d'une classe qui hérite de 2 Interfaces qui implémentent la même méthode ? On se retrouve avec le même "problème".

ca ne change pas grand chose je pense, enfin quand tu implémentes 2 interfaces avec une méthode de même nom et même signature il fallait déjà spécifier
ca reviendra au même je pense, enfin ce n'est pas précisé oui, car j'ai cru comprendre que ce n'était pas un override mais bien une récupération implicite, donc il faudrait pouvoir en réorienter une alors qu'aucune des 2 n'apparaitra ...

Concernant le "range", le point qui me chagrine est que le comptage part de 0 au début de la chaine, et de 1 à la fin.
Dans cet exemple, l'indice 1 est le second caractère, et l'indice ^1 le dernier. Pourquoi ce n'est pas ^0 ?

il faut plus le voir comme un count - n donc count - 1 ramène bien à la fin

Ça c'est justement un cas où ça me paraîtrait inapproprié. D'un point de vue fonctionnel un IViewModel ne devrait pas permettre à son consommateur de lever lui-même l'événement, après tout seul le ViewModel peut dire si une de ses propriétés à réellement changé sa valeur (puisqu'il pourrait par exemple bloquer l'affectation d'une valeur invalide). Ce genre de méthode n'a ça place que dans la structure interne d'une classe et ne devrait pas être dans une interface. Si on veut factoriser ce code on le ferait dans une classe de base (éventuellement abstract) qui serait héritée par d'autres classes

l'appel à RaisePropertyChanged restera dans la classe sur chaque propriété, donc c'est bien la classe qui saura s'il faut lever l'event (au passage avec [CallerMemberName] ca évite de préciser le nom de la propriété)
après passer par une classe type ObservableObject pour en hériter ca n'est pas toujours possible, en wpf par exemple on a souvent envie d'hériter de dependencyobject, donc avoir une interface avec du code ca amène quand même un peu de souplesse

après libre à chacun d'utiliser ou non
moi c'est l'object nullable que je vois pas trop les cas d'utilisations