IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    novembre 2016
    Messages
    129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2016
    Messages : 129
    Points : 440
    Points
    440
    Par défaut
    Que va-t-il advenir de string.IsNullOrWhiteSpace() ?
    Oui, je me pose des questions existentielles.

  2. #22
    Membre chevronné
    Avatar de stailer
    Homme Profil pro
    Architecte technique
    Inscrit en
    mars 2003
    Messages
    1 135
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hautes Pyrénées (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2003
    Messages : 1 135
    Points : 2 144
    Points
    2 144
    Billets dans le blog
    3
    Par défaut
    Que va-t-il advenir de string.IsNullOrWhiteSpace() ?
    Je pense que c'est toujours utile car comme son nom l'indique ça vérifie aussi si ta chaîne n'est pas constituée que d'espaces blancs
    .o0o__St@iLeR__oOo.

    Lead Developer

    ASP.NET MVC - MCP/MCSD ASP.NET
    PHP Zend Framework / PhalconPHP
    Cordova/Xamarin IOS/Android
    Kendo UI - ExtJS - JQwidgets
    SQL Server / MySQL

  3. #23
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    juillet 2005
    Messages
    562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2005
    Messages : 562
    Points : 1 511
    Points
    1 511
    Par défaut
    Citation Envoyé par stailer Voir le message
    Je pense que c'est toujours utile car comme son nom l'indique ça vérifie aussi si ta chaîne n'est pas constituée que d'espaces blancs
    Comme CS_FS je me pose des questions existancielles !
    Ok pour WhiteSpace ! Mais quid de IsNullOrEmpty() ?

    Sinon je valide les évolutions mais je suis pas fan d'omettre les types, je minimise l'utilisation des var , quasis que pour des tests ponctuels, je trouve ça inutile et vraiment pas pratique lors de la reprise de code ou lors de débogage.

    J@ck.
    Pas de réponse par MP, merci.

    Penser au ça fait plaisir

  4. #24
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    422
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2006
    Messages : 422
    Points : 919
    Points
    919
    Par défaut
    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);
    }
    }
    "S'adapter, c'est vaincre" - Cellendhyll de Cortavar

  5. #25
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 497
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 497
    Points : 10 663
    Points
    10 663
    Par défaut
    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".

    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.
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    Index i1 = 1;  // number 1 from beginning
    Index i2 = ^1; // number 1 from end
    int[] a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    Console.WriteLine($"{a[i1]}, {a[i2]}"); // "1, 9"

    Dans cet exemple, l'indice 1 est le second caractère, et l'indice ^1 le dernier. Pourquoi ce n'est pas ^0 ?

    Tatayo.

  6. #26
    Membre chevronné
    Homme Profil pro
    edi
    Inscrit en
    juin 2007
    Messages
    847
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : edi

    Informations forums :
    Inscription : juin 2007
    Messages : 847
    Points : 1 816
    Points
    1 816
    Par défaut
    Citation Envoyé par Kikuts Voir le message
    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.

  7. #27
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 711
    Points : 4 405
    Points
    4 405
    Par défaut
    Ces références nullables sont les bienvenues, mais peuvent mener à des trucs lourds / contre-intuitifs..

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    string? str = "blah";
     
    if(!string.IsNullOrEmpty(str) { Console.Out.WriteLine(str.Length); } // utilisation comme une ref "classique" ?
    if(!string.IsNullOrEmpty(str?.Value)) { Console.Out.WriteLine(str.Value.Length); } // ou comme un Nullable<T> ?
     
    int foo = null; // erreur
    string bar = null; // warning
     
    if(bar == null) { } // vrai ? faux ? erreur ? warning ?

  8. #28
    Membre actif
    Homme Profil pro
    Dev
    Inscrit en
    novembre 2006
    Messages
    100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev

    Informations forums :
    Inscription : novembre 2006
    Messages : 100
    Points : 297
    Points
    297
    Par défaut
    Citation Envoyé par tatayo Voir le message
    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#

  9. #29
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    avril 2007
    Messages
    13 944
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 13 944
    Points : 24 613
    Points
    24 613
    Par défaut
    Citation Envoyé par tatayo Voir le message
    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 ...

    Citation Envoyé par tatayo Voir le message
    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


    Citation Envoyé par Noxen Voir le message
    Ç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
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  10. #30
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 639
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 639
    Points : 10 354
    Points
    10 354
    Billets dans le blog
    21
    Par défaut
    Citation Envoyé par miaous Voir le message
    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.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  11. #31
    Membre confirmé
    Profil pro
    Inscrit en
    avril 2008
    Messages
    442
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 442
    Points : 582
    Points
    582
    Par défaut
    Citation Envoyé par J@ckHerror Voir le message
    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"

  12. #32
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 639
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 639
    Points : 10 354
    Points
    10 354
    Billets dans le blog
    21
    Par défaut
    Citation Envoyé par ijk-ref Voir le message
    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", "t'es un mauvais programmeur pour que ça te dérange"
    Je ne dis pas que ce n'est pas une erreur. Je dis que corriger les choses maintenant au lieu de les avoir prévu dès le début va provoquer des incompatibilités. C# se retrouve donc a être comme PHP ou Python, où une montée de version majeure induit un cassage de la compatibilité. Et que ça, c'est aussi une très grosse erreur (peut être même plus que l'erreur que l'on souhaite corriger). Jusqu'à présent, l'ajout de nouvelles fonctionnalités s'était toujours fait de manière compatible.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  13. #33
    Membre confirmé
    Profil pro
    Inscrit en
    avril 2008
    Messages
    442
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 442
    Points : 582
    Points
    582
    Par défaut
    Citation Envoyé par François DORIN Voir le message
    Je ne dis pas que ce n'est pas une erreur. Je dis que corriger les choses maintenant au lieu de les avoir prévu dès le début va provoquer des incompatibilités. C# se retrouve donc a être comme PHP ou Python, où une montée de version majeure induit un cassage de la compatibilité. Et que ça, c'est aussi une très grosse erreur (peut être même plus que l'erreur que l'on souhaite corriger). Jusqu'à présent, l'ajout de nouvelles fonctionnalités s'était toujours fait de manière compatible.
    Si on avait la solution avant de commettre une erreur… on ne ferait… du coup… plus jamais d'erreurs

  14. #34
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 639
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 639
    Points : 10 354
    Points
    10 354
    Billets dans le blog
    21
    Par défaut
    Tony Hoare (le père de la valeur null), sous-entendait largement en 1995 que le null était une énorme bêtise. Il a même fait son mea culpa en 2010 pour "avoir inventé la référence null" (son erreur à 1 milliard de dollars comme il aime à l'appeler). Donc, l'erreur était connue depuis bien avant la création du C#, dont la première version date de 2002
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  15. #35
    Membre confirmé
    Profil pro
    Inscrit en
    avril 2008
    Messages
    442
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 442
    Points : 582
    Points
    582
    Par défaut
    Et pourtant en 2017 en découvrant cette suggestion combien d'entre nous l'avons comprise du premier coup ? La grande majorité (moi y compris) ne comprenait même pas où ils voulaient en venir.


    Alors il y a plus de 15 ans… même parmi les meilleurs spécialistes des langages… ce n'est parce qu'ils avaient connaissance d'un défaut qu'ils en avaient une solution mature.

  16. #36
    Membre averti
    Profil pro
    Inscrit en
    février 2008
    Messages
    145
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : février 2008
    Messages : 145
    Points : 337
    Points
    337
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    ...
    Pour cela, elle vous empêche de mettre null dans des types de référence ordinaire comme string.
    Sauf que la classe String n'est pas un type ordinaire. C'est une type immuable, très particulier dans le .NET (et le java aussi il me semble).

    Citation Envoyé par Michael Guilloux Voir le message
    Cette fonctionnalité devrait donc casser le code existant. Un problème que Microsoft a décidé de gérer en douceur en générant des avertissements et non des erreurs. Toujours est-il qu'un code propre d'aujourd'hui pourra se retrouver avec des milliers d'avertissements demain. Vous devez donc choisir d'utiliser la fonctionnalité (ce que vous pouvez faire au niveau du projet, du fichier ou même de la ligne de code source).
    Il me semblait que ce n'était et resterait toujours qu'un warning. Quid de la classe Nullable<> pour les types références dans ce cas ?

    Citation Envoyé par ijk-ref Voir le message
    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"
    Il existe déjà l'opérateur .? qui simplifie l'écriture du code et sa lisibilité. Et ça évite les NullReferenceException .

    Et puis les mauvais programmeurs, c'est ceux qui ne testent pas leurs codes avec tous les cas tordus et des données pourries. Et les valeurs null en font parti.

    Citation Envoyé par Michael Guilloux Voir le message
    ...
    Microsoft a ajouté un type Index, qui peut être utilisé pour l’indexation. Vous pouvez en créer un à partir d'un intqui permet de compter depuis le début, ou avec un opérateur de préfixe ^ qui permet de compter depuis la fin.
    Je ne vois pas trop l'intérêt de la chose. Et la syntaxe me parait hasardeuse avec le ^. ça va faire de bugs tout ça.

    Citation Envoyé par Michael Guilloux Voir le message
    ...
    C# introduit aussi les modèles récursifs (les modèles contenant d'autres modèles), et l'implémentation par défaut des membres d'une interface. Dans le dernier cas notamment, aujourd’hui, une fois que vous publiez une interface, vous ne pouvez pas ajouter de membres sans casser tous les implémenter existants, explique Microsoft. Dans C# 8.0, la firme vous permet de fournir un corps pour un membre d'interface.
    Ajouter du code dans une interface c'est un peu antinomique. Et avoir un code par défaut, implémenté par "quelqu'un", ça peut même être dangereux.

    Citation Envoyé par Michael Guilloux Voir le message
    Ainsi, si quelqu'un n'implémente pas ce membre (peut-être parce qu'il n'était pas encore là quand il a écrit son code), il obtient simplement l'implémentation par défaut.
    Dans ce cas là, je préfère que le compilateur lui crache une erreur, plutôt que ça passe inaperçu. Et je pense que pour la qualité du code, c'est salvateur.

  17. #37
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2016
    Messages
    1 848
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 1 848
    Points : 40 612
    Points
    40 612
    Par défaut C# 8.x va introduire la fonctionnalité Records pour faciliter la création des classes POCO
    C# 8.x va introduire la fonctionnalité Records pour faciliter la création des classes POCO
    selon Developers Anonymous

    Developers Anonymous a annoncé dans un billet de blogue ce week-end que la fonctionnalité Records destinée à faciliter la création de classes POCO sera introduite à partir de l’une des versions de la branche C# 8.x, mais pas dans C# 8.0. Selon Developers Anonymous, Microsoft inclura cette fonctionnalité un peu plus tard, car pour le moment, l’effort est consenti sur d’autres fonctionnalités jugées plus importantes et plus utiles pour la sortie du C# 8.0. « Soyons clairs. Cela avait été initialement prévu pour la version 8 de C#, mais en raison d’autres fonctionnalités plus importantes et de la complexité de cette fonctionnalité, il a été reporté pour une version ponctuelle, peut-être la version 8.1 ou la 8.2, etc. », a expliqué le site à propos de la fonctionnalité.

    Cette version majeure du langage C# est en préparation depuis un certain temps. Le plan de l'entreprise est que C# 8.0 soit livré en même temps que .NET Core 3.0. Le premier aperçu de cette version du langage a été publié par la firme en novembre dernier. Dans cette préversion, quelques fonctionnalités faisaient leur apparition notamment les types de références nullables, les flux asynchrones et les types Range et Index. D’autres fonctionnalités telles que les modèles récursifs (des modèles qui contiennent d’autres modèles) et les expressions Switch sont également prévues pour C# 8.0.

    Nom : z2.png
Affichages : 8441
Taille : 50,9 Ko

    La Preview 2 publiée il y a quelques semaines par Microsoft apporte encore plus de fonctionnalités que la première avec de nombreuses améliorations. On peut citer entre autres : une amélioration de la correspondance des modèles, les expressions Switch comme annoncées dans le premier aperçu, les modèles de tuple, les fonctions locales statiques et les structures, etc. Microsoft ne l’a encore souligné nulle part ailleurs, mais Developers Anonymous annonce que la fonctionnalité Records sera dans l’une des versions de la branche 8.x. Cette fonctionnalité va permettre de définir, à l’avenir, une classe POCO de manière plus simple et plus explicite.

    Si vous n’êtes pas habitué au terme POCO, il s’agit de l'abréviation de Plain Old CLR Object. Un objet POCO (Plain Old CLR Object) est une classe, qui ne dépend d'aucune classe de base spécifique à l'infrastructure. C'est comme n'importe quelle autre classe .NET normale. Ces entités POCO (également appelées objets ignorant la persistance) prennent en charge la plupart des mêmes requêtes LINQ que les entités dérivées de l'objet entité. Ces classes (classes POCO) implémentent uniquement la logique métier du domaine de l'application. Le POCO en .NET Framework possède des équivalents dans les autres langages tels que POJO (Plain Old Java Object) en Java, le POPO (Plain Old PHP Object) en PHP, le PONSO (Plain Old NSObject) en Objective-C, etc.

    Très souvent, explique le site Developers Anonymous, écrire le code pour ces classes revient à écrire beaucoup de code passe-partout. C’est à ce stade que C# 8.x vient simplifier le processus de création de ces classes en introduisant Records. La syntaxe des enregistrements permet au compilateur de faire tout le travail pour le développeur et de produire ce code sans qu’il ne l'écrive. Contrairement aux extraits de code dans lesquels le développeur utilise simplement une touche de raccourci pour générer un modèle de code à remplir, la nouvelle syntaxe indique simplement au compilateur le type de classe qu’il veut et le compilateur le génère pour lui. Voici un exemple de ce qu’explique ce blog :

    public class Person(string Name, string Surname, string Address, DateTime DateOfBirth);.

    Le résultat généré par cette ligne de code est étendu à une classe beaucoup plus grande qui implémente également IEquatable avec des méthodes telles que GetHashCode(), Equals(), Deconstruct(), etc.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
     
    using System;
     
    public class Person: IEquatable<Person>
    {
        public string Name { get; }
        public string Surname { get; }
        public string Address { get; }
        public DateTime DateOfBirth { get; }
     
        public Person(string Name, string Surname, string Address, DateTime DateOfBirth)
        {
            this.Name = Name;
            this.Surname = Surname;
            this.Address = Address;
            this.DateOfBirth = DateOfBirth;
        }
     
        public bool Equals(Person other)
        {
            return Equals(Name, other.Name) && Equals(Surname, other.Surname) && Equals(Address, other.Address) && Equals(DateOfBirth, other.DateOfBirth);
        }
     
        public override bool Equals(object other)
        {
            return (other as Person)?.Equals(this) == true;
        }
     
        public override int GetHashCode()
        {
            return (Name.GetHashCode() * 17 + Surname.GetHashCode() + Address.GetHashCode() + DateOfBirth.GetHashCode());
        }
     
        public void Deconstruct(out string Name, out string Surname, out string Address, out DateTime DateOfBirth)
        {
            Name = this.Name;
            Surname = this.Surname;
            Address = this.Address;
            DateOfBirth = this.DateOfBirth;
        }
     
        public Person With(string Name = this.Name, string Surname = this.Surname, string Address = this.Address, DateTime DateOfBirth = this.DateOfBirth) => new Person(Name, Surname, Address, DateOfBirth);
    }
    Le compilateur propose une implémentation de la méthode Deconstruct() lors de la génération du code de la classe. Cette méthode, indique Developers Anonymous, va permettre à l’utilisateur de simplement déconstruire une instance de cette classe avec une syntaxe très similaire à ValueTuple.

    Toutefois, les internautes ne semblent pas très enthousiastes à la lecture de ce billet. Par exemple, beaucoup d’entre eux sur les réseaux sociaux discutent cette affirmation du site. Selon ces derniers, cette fonctionnalité est remise en cause depuis sa proposition à la version 6 du langage et jusque là, aucune publication de Microsoft n’indique qu’elle fera l’objet d’une étude approfondie pour sa prise en charge par C# 8.1 ou supérieur.

    Source : Billet de blog

    Et vous ?

    Qu'en pensez-vous ?
    Cette fonctionnalité sera-t-elle vraiment prise en charge dans C# 8.x ?

    Voir aussi

    Microsoft revient avec plus de détails sur .NET Core 3.0 et .NET Framework 4.8 bientôt une dissemblance entre le Framework .NET et .NET Core

    Microsoft livre un aperçu des nouveautés de C# 8.0 et envisage de commencer à livrer cette version dans les préversions de Visual Studio 2019

    Visual Studio Code 1.29 est disponible : aperçu des nouveautés dans l'éditeur de code open source et multiplateforme de Microsoft

    Microsoft livre un aperçu des changements de l'expérience et l'interface utilisateur dans Visual Studio 2019, la prochaine version majeure de son EDI

    Microsoft annonce que ASP.NET Core 3.0 fonctionnera uniquement sur .NET Core 3.0 et ne sera plus compatible avec la plateforme .NET Framework
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  18. #38
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    avril 2007
    Messages
    13 944
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 13 944
    Points : 24 613
    Points
    24 613
    Par défaut
    moi je vois plus ça pour un DTO

    un poco chez moi ce sont des dependency properties (wpf oblige), et chez d'autres il y a INotifyPropertyChanged, et chez encore d'autres ce sont les DTO qui ont
    INotifyPropertyChanged … (sans parler de ceux qui utilisent EF et qui ont surement moins ces problématiques)
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

Discussions similaires

  1. Microsoft dévoile la feuille de route de son service Cloud OneDrive
    Par Stéphane le calme dans le forum Cloud Computing
    Réponses: 3
    Dernier message: 12/01/2015, 14h21
  2. Microsoft dévoile la feuille de route d'Office 365 version entreprise
    Par Stéphane le calme dans le forum Microsoft Office
    Réponses: 0
    Dernier message: 20/06/2014, 19h42
  3. BizTalk Server 2010 R2 : Microsoft dévoile la feuille de route
    Par Hinault Romaric dans le forum Microsoft BizTalk Server
    Réponses: 0
    Dernier message: 09/12/2011, 11h17
  4. Réponses: 15
    Dernier message: 04/10/2010, 08h52
  5. Réponses: 0
    Dernier message: 22/04/2010, 19h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo