+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 856
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 856
    Points : 62 878
    Points
    62 878

    Par défaut Microsoft a dévoilé la feuille de route de C # 7.1, C # 7.2 et C # 8.0

    Microsoft a dévoilé la feuille de route de C # 7.1, C # 7.2 et C # 8.0,
    et propose quelques améliorations à son langage

    C # 7.1

    async Task Main()

    Les mots clés async et await, qui ont été apportés par C # 5.0 facilitent l’écriture du code qui appelle des systèmes externes, ou fait des E/S, sans bloquer un thread. Cela rend les applications Web évolutives et conserve la réactivité des IU d’applications.

    Cependant, une fois qu'une partie de votre code est asynchrone, tout ce qui implique ce code doit également devenir asynchrone. Lorsque votre application d'hébergement est une application de console ou un service Windows, cela pose un problème. Vous pouvez écrire async void Main, mais cela signifie que, dès que vous arrivez à votre premier await, l’application entière se termine.

    La raison ? async void, qui agit comme un mécanisme de prévention des incendies. Étant donné que vous ne pouvez pas retourner une Task de Main, vous devrez utiliser quelque chose comme AsyncContext depuis la bibliothèque AsyncEx.

    Microsoft explique que cela ne sera plus nécessaire : le compilateur et le framework reconnaîtront et exécuteront correctement une méthode Async Task Main.

    Les expressions default :

    Il s'agit simplement d'une amélioration de quelque chose qui a été supporté depuis C # 2.0 et l'avènement des génériques, en 2005. Il est sous forme de default (T), où T est bien sûr un type. Pour les types de référence, il représente null, et pour les types de valeurs tels que int, il représente la valeur par défaut, non initialisée, de ce type.

    La nouvelle fonctionnalité est que, lorsque le type de T peut être déduite, il n'est plus nécessaire de le spécifier.

    En clair, au lieu d’écrire ceci

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    int x = default(int);

    Vous pourrez écrire ceci


    Bien sûr, cela s'étend également à d'autres usages de default, tels que les déclarations de retour, les valeurs par défaut pour les arguments, et, en développant le point précédent, les expressions ternaires.

    Pour illustrer, ceci sera valide dans une future version de C #

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    var x = flag ? 1: default;
    :
    Déduction des tuples

    Supposons que vous voulez créer le tuple (string Nom, string Prenom) et que vous avez déjà des variables locales appelées Nom et Prenom. Vous devez écrire quelque chose comme ceci :
    var t = (fNom: Prenom, SecondNom: SecondPrenom);Cette fonctionnalité va déduire les noms des éléments de tuple à partir de leur expression d'initialisation, un peu comme ce que vous pouvez faire avec des types anonymes.

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    var t = (Nom, SecondNom);
     
    Console.WriteLine($"Salut, {t.Nom}!");

    C # 7.2

    Références read-only

    Ici, il s’agit de donner à C # la possibilité d'utiliser des paramètres const-like pour améliorer les performances. Connu sous le nom de « paramètres réellement définis » ou « paramètres » simples, ceux-ci permettent de transmettre de grandes structures par référence tout en ne permettant pas qu'elles soient mutées.

    C # 8.0

    Types de référence nullables

    L'équipe responsable du développement de C # a, pour l'instant, choisi de faire en sorte que tous les types de référence deviendront non annulables par défaut, et vous pouvez faire en sorte qu’un type de variable soit nullable en vous servant de “?”. L'utilisation d'une variable non nulle qui pourrait être nulle (car vous ne l'avez pas vérifiée si elle avait déjà pris cette valeur) entraînera un avertissement, tout en attribuant la valeur d'une variable nulle à celle qui n'est pas nullable.

    Petit exemple d’illustration

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    // bar est nullable parce que son type est string?
    void Foo(string? bar)  
    {
        string baz = bar; 
        // ceci va générer un avertissement parce que baz est non-nullable 
        // mais bar est nullable
    }
    Pour résoudre ce problème, il suffit de vérifier que bar n’est pas null

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    void Foo(string? bar)  
    {
        if (bar == null)
            throw new ArgumentNullException(nameof(bar));
     
        string baz = bar; 
    }

    Source : feuille de route
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2004
    Messages : 19 829
    Points : 40 600
    Points
    40 600

    Par défaut

    A noter que si les choses sont à peu près figées pour C# 7.1, ce n'est pas le cas pour les versions suivantes (les features sont encore à l'état de proposition ou de prototype).

    Une autre feature très intéressante envisagée pour C# 8, c'est les méthodes par défaut dans les interfaces, un peu comme en Java 8. Ça permet de mettre dans une interface une méthode avec une implémentation. L'intérêt est multiple :
    • une classe qui implémente l'interface n'est pas obligée d'implémenter elle-même ces méthodes, puisqu'une implémentation par défaut existe
    • une classe qui implémente l'interface peut redéfinir ces méthodes, par exemple si elle peut en faire une implémentation plus efficace que celle par défaut
    • on peut ajouter des méthodes par défaut à une interface sans que ce soit un breaking change (normalement, ajouter un membre à une interface d'une API publique est un breaking change, puisque les classes qui implémentent déjà l'interface doivent être modifiées)
    • ça apporte à C# une forme allégée d'héritage multiple (allégée car une interface ne peut pas déclarer de champs, seulement des méthodes, propriétés ou événements)

  3. #3
    Membre régulier
    Profil pro
    retraité
    Inscrit en
    décembre 2010
    Messages
    63
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : décembre 2010
    Messages : 63
    Points : 98
    Points
    98

    Par défaut

    Citation Envoyé par tomlev Voir le message
    A noter que si les choses sont à peu près figées pour C# 7.1, ce n'est pas le cas pour les versions suivantes (les features sont encore à l'état de proposition ou de prototype).

    Une autre feature très intéressante envisagée pour C# 8, c'est les méthodes par défaut dans les interfaces, un peu comme en Java 8. Ça permet de mettre dans une interface une méthode avec une implémentation. L'intérêt est multiple :
    • une classe qui implémente l'interface n'est pas obligée d'implémenter elle-même ces méthodes, puisqu'une implémentation par défaut existe
    • une classe qui implémente l'interface peut redéfinir ces méthodes, par exemple si elle peut en faire une implémentation plus efficace que celle par défaut
    • on peut ajouter des méthodes par défaut à une interface sans que ce soit un breaking change (normalement, ajouter un membre à une interface d'une API publique est un breaking change, puisque les classes qui implémentent déjà l'interface doivent être modifiées)
    • ça apporte à C# une forme allégée d'héritage multiple (allégée car une interface ne peut pas déclarer de champs, seulement des méthodes, propriétés ou événements)
    En gros il refont ce qui existe déjà avec les classes abstraites en C++. Je ne connais pas C# mais sauf erreur de ma part Java avait rajouté la généricité, la création des opérateurs...à la longue il faut faire gaffe cela va devenir du C++

  4. #4
    Membre actif Avatar de WaterTwelve21
    Homme Profil pro
    Développeur .NET
    Inscrit en
    décembre 2015
    Messages
    177
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : décembre 2015
    Messages : 177
    Points : 273
    Points
    273

    Par défaut

    Je ne connais pas C# mais sauf erreur de ma part Java avait rajouté la généricité, la création des opérateurs...à la longue il faut faire gaffe cela va devenir du C++
    Peut-être que c'est parce que ca fait bien longtemps que la généricité et la création des opérateurs ont été mis en place. Avec c#7 il n'y a pas de révolutions à proprement parler mais on ressent la volonté de toujours améliorer le quotidien du developpeur et puis les tuples les méthodes aux retour multiple etc ... c'est quand même pas mal.

    C'est presque dommage que ca aille si vite ( ou que les entreprises ne suivent pas ) .
    throw new NoSignatureException();

  5. #5
    Membre actif
    Profil pro
    Inscrit en
    avril 2008
    Messages
    290
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 290
    Points : 288
    Points
    288

    Par défaut

    Bonjour j'aimerai bien savoir ce que vous penseriez d'une amélioration de langage bien plus souple et puissante concurrente à la gestion des exceptions et des variables de sorties 'out' ?

    A mon avis ces méthodes classiques :
    Code c# : 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
    int Parse(string s)
    {
      if(...) return 42;
      throw new Exception(...)
    }
     
    int Parse(string s, int defaut_val)
    {
      if(...) return 42;
      return defaut_val;
    }
     
    bool TryParse(string s, out int i)
    {
      if(...) { i = 42; return true; }
      i = default(int); return false;
    }

    Pourraient être avantageusement remplacées par une seule :
    Code c# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    int MyParse(string s) | void MyError()
    {
      if(...) MyParse.return 42;
      MyError.return;
    }

    Et pouvant s'utiliser comme cela :
    Code c# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    int i0 = MyParse("42"); // lancerait une exception classique en cas où la sortie "MyError" serait atteinte
     
    int i1 = MyParse("42") | MyError() -1; // renvoie -1 en cas parsage incorrecte - dans tous les cas aucune exception créée
     
    MyParse("42")->(int i2)
    {
      // sortie ici en cas de parsage correcte - 'i2' est visible naturellement qu'ici
    }
    |MyError() // sortie facultative 
    {
      // sortie ici en cas de parsage incorrecte - évidemment aucune exception créée non plus 
    }

    Ne trouverez vous pas cela plus efficace ?

  6. #6
    Membre averti
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 194
    Points : 310
    Points
    310

    Par défaut

    A quand des outils RAD comme Delphi comme ca avait existé il y a bien longtemps et qui permettait a quiconque de "programmer" rapidement sans se prendre la tete ?
    En 2017 on galere toujours autant a developper des applis avec IHMs (asp.net ou mobile ou desktop).
    Alors certes les langages evoluent dans leur syntaxe mais au final ce qu'on vend au client c'est un fonctionnel et je constate qu'on n'est pas plus performant en 2017 qu'en 1990 pour developper des applis IHMs (qu'on ait eu a ecrire 3 lignes de codes au lieu de 2 n'est pas une fin en soi, qu'on code du portable ou du modulaire, et a la techno suivante on jette tout et on recommence (ex: experience silverlight/wpf)).
    Dev ASM/C/C++ au depart je vois que les evolutions des langages frisent quelques fois a l'inutilité (ex : auto en C++) voir des anti patterns.

    Je sais que c'est propre au developpeur (j'en suis un) de jouer avec les technos/langages et defaire/refaire regulierement la meme chose ... mais differemment mais au final on s'occupe plutot qu'autre chose. Certes apres 30 ans de dev j'ai un peu perdu tout espoir et je vois beaucoup de choses produites mais au final ca se resume souvent a 'tout ca pour ca'.

  7. #7
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2004
    Messages : 19 829
    Points : 40 600
    Points
    40 600

    Par défaut

    Citation Envoyé par ijk-ref Voir le message
    Bonjour j'aimerai bien savoir ce que vous penseriez d'une amélioration de langage bien plus souple et puissante concurrente à la gestion des exceptions et des variables de sorties 'out' ?
    J'en pense que tu avais déjà mentionné cette idée il y a quelques mois, que j'avais trouvé que c'était une très mauvaise idée, et que mon avis n'a pas changé depuis . D'une part parce que c'est incompréhensible, et d'autre part parce que ce n'est pas du tout cohérent avec la syntaxe existante du langage.

    D'ailleurs en C# 7 on peut déjà faire des choses tout à fait propres et lisibles pour ce genre de situation :

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    if (TryParse("42", out var i))
    {
        // i vaut 42
    }
    else
    {
        ...
    }

    Tu peux toujours aller proposer ton idée sur Github, mais je doute qu'elle soit accueillie très favorablement...

  8. #8
    Membre éprouvé Avatar de worm83
    Homme Profil pro
    Architecte technique
    Inscrit en
    février 2010
    Messages
    456
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Conseil

    Informations forums :
    Inscription : février 2010
    Messages : 456
    Points : 1 067
    Points
    1 067

    Par défaut

    J'avais pas très bien compris le "ckeck nullable" de c# 8, tel que tu l'avais présenté.

    Le but n'est pas réellement de forcer les référence a ne plus être nullable, comme je l'ai compris dans ton papier (ce qui serait une hérésie), mais de forcer les développeur à vérifier le fait que celle-ci n'est pas "null".

    Et pour le coup c'est très intéressant lorsque l'on monte une archi/Framework, en appliquant certaines convention à l'équipe, on peut forcer à appliquer une programmation "défensive" sur certains socle de l’application, ou au contraire laisser sous-entendre entendre que la valeur et les limites de celle-ci a déjà été vérifiée via les signatures d'interface et éviter une revérifications des limites.

    Le langage suit une bonne évolution.

    Concernant ta proposition ijk-ref, je suis de l'avis de Tom, pas du tout intéressé.


    Merci pour ce post tom.
    "Le train de tes injures roule sur le rail de mon indifférence."

    "Monde de merde !!"

    Georges Abitbol.

  9. #9
    Membre actif
    Profil pro
    Inscrit en
    avril 2008
    Messages
    290
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 290
    Points : 288
    Points
    288

    Par défaut

    Tomlev et Worm83 merci pour m'avoir au moins donné votre avis - vous Même si j'aurai aimé un peu plus d'enthousiaste

    Citation Envoyé par tomlev Voir le message
    J'en pense que tu avais déjà mentionné cette idée il y a quelques mois, que j'avais trouvé que c'était une très mauvaise idée, et que mon avis n'a pas changé depuis .
    Non personne ne m'avait encore donné son avis sur cette idée. C'en était une autre beaucoup moins 'aboutie' et générale.


    Citation Envoyé par tomlev Voir le message
    D'une part parce que c'est incompréhensible, et d'autre part parce que ce n'est pas du tout cohérent avec la syntaxe existante du langage.
    Incompréhensible !? La seule différence de code est le remplacement des "throw new Exception" par des "return nommé". La syntaxe ne change absolument pas si on utilise ces méthodes 'classiquement'. Ensuite il faut bien partir sur une nouvelle syntaxe si l'on souhaite accéder aux différentes "sorties".

    Du point de vue du compilateur c'est informativement plus précis... contrairement justement au "if (TryParse("42", out var i))" qui est (bien sur) humainement lisible mais bien moins efficace pour le compilateur. De plus ceci ne fait pas ce que l'on souhaite : retourner une valeur dans la portée de sa validité - ce que ne permettra jamais un "if-methode-out" puisque ce n'est que du bidouillage.

    Mais p'être que je devrais m'y prendre autrement pour me faire comprendre.

    Imaginez que vous aillez besoin d'une "méthode" devant retourner 1 valeur... mais pouvant être de 3 types différents... et qu'en bon "autiste" adepte du typage fort vous aimeriez avoir les outils pour que ce soit le compilateur qui se charge de cette vérification... quelle syntaxe aimeriez-vous avoir à votre disposition pour parfaire ce fantasme ?

    Je vous montre la mienne :

    Code c# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    Event0(mouseMove)->(var r)
    {
      label.Content = "location : " + r.GetPosition(this);
    }
    |Event1(mouseDown)->(var r)
    {
      label.Content = "button : " + r.MouseButton;                
    }
    |Event2(keyDown)->(var r)
    {
      label.Content = "key : " + r.Key;                
    }

    Remplaçant avantageusement :

    Code c# : 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
    var (index, result) = MyEvents(mouseMove, mouseDown, keyDown);
    switch (index)
    {
      case 0:
      {
        var r = (MouseEventArgs)result;
        label.Content = "location : " + r.GetPosition(this);
      }
      break;
      case 1:
      {
        var r = (MouseButtonEventArgs)result;
        label.Content = "button : " + r.MouseButton;
      }
      break;
      case 2:
      {
        var r = (KeyEventArgs)result;
        label.Content = "key : " + r.Key;
      }
      break;
    }

  10. #10
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2004
    Messages : 19 829
    Points : 40 600
    Points
    40 600

    Par défaut

    Citation Envoyé par ijk-ref Voir le message
    Imaginez que vous aillez besoin d'une "méthode" devant retourner 1 valeur... mais pouvant être de 3 types différents... et qu'en bon "autiste" adepte du typage fort vous aimeriez avoir les outils pour que ce soit le compilateur qui se charge de cette vérification... quelle syntaxe aimeriez-vous avoir à votre disposition pour parfaire ce fantasme ?

    Je vous montre la mienne :
    Pourquoi un "index" pour représenter le type ?

    Moi je te montre la mienne :

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    var result = MyEvents(mouseMove, mouseDown, keyDown);
    switch (result)
    {
      case MouseButtonEventArgs r:
        label.Content = "button : " + r.MouseButton;
        break;
      case MouseEventArgs r:
        label.Content = "location : " + r.GetPosition(this);
        break;
      case KeyEventArgs r:
        label.Content = "key : " + r.Key;
        break;
    }

    C'est du C# 7, on peut déjà faire ça aujourd'hui sans inventer une nouvelle syntaxe bizarre.

    Donc non, je suis toujours pas convaincu...

    (note que j'ai réordonné les cases, parce que MouseButtonEventArgs hérite de MouseEventArgs, donc si MouseEventArgs est avant, il chopera aussi les MouseButtonEventArgs... c'est comme avec les catch, il faut intercepter l'exception la plus spécifique en premier)

    Remplaçant avantageusement :
    C'est très discutable... tu as le droit de préférer ça, mais personnellement je trouve ça affreux, et ça ne ressemble même pas à du C#.

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

    Informations forums :
    Inscription : avril 2008
    Messages : 290
    Points : 288
    Points
    288

    Par défaut

    Citation Envoyé par tomlev Voir le message
    Pourquoi un "index" pour représenter le type ?
    Parce que rien n'empêche d'utiliser des évènements différents retournant le même type demandant chacun son traitement particulier.

    Citation Envoyé par tomlev Voir le message
    C'est du C# 7, on peut déjà faire ça aujourd'hui sans inventer une nouvelle syntaxe bizarre.
    Non C# 7 ne permet absolument de faire cela. Par contre ma syntaxe permettrait de coder nous-même des outils aussi puissants que ce nouveau switch.

    Citation Envoyé par tomlev Voir le message
    Donc non, je suis toujours pas convaincu...

    (note que j'ai réordonné les cases, parce que MouseButtonEventArgs hérite de MouseEventArgs, donc si MouseEventArgs est avant, il chopera aussi les MouseButtonEventArgs... c'est comme avec les catch, il faut intercepter l'exception la plus spécifique en premier)
    Super, tout ce qu'il est souhaitable d'éviter pour un traitement d'évènements (ou de messages etc...)

    Dans la réalité t'auras surement une boucle de massages plus conséquente à traiter. Ma méthode permet d'en insérer une naturellement à la suite des autres sans cette erreur de typage possible. De plus chaque traitement est avec sa déclaration. Faut être un peu de mauvaise foi pour préférer avoir toutes les déclarations au début et s'y retrouver sans erreur dans les traitements suivants - qui ne seront pas toujours comme notre exemple basique avec des types de retour uniques et aussi lisibles.

    Citation Envoyé par tomlev Voir le message
    C'est très discutable... tu as le droit de préférer ça, mais personnellement je trouve ça affreux, et ça ne ressemble même pas à du C#.
    Drôle d'argument, les requêtes Linq, les expressions lambda ne ressemblaient pas plus à du C#

    Après même si je trouve une certaine élégance et concision à ma syntaxe, n'hésite à faire une proposition si t'en penses une plus claire - ayant au moins les mêmes avantages

  12. #12
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2004
    Messages : 19 829
    Points : 40 600
    Points
    40 600

    Par défaut

    Citation Envoyé par ijk-ref Voir le message
    Faut être un peu de mauvaise foi
    Merci d'éviter les attaques personnelles. Ce n'est pas parce que je ne suis pas d'accord avec toi que je suis de mauvaise foi. Tu as le droit de préférer ta syntaxe, et moi j'ai le droit de la trouver toute pourrie. Si tu veux forker le compilateur C# pour implémenter ça, libre à toi...

    Pour ma part, j'ai dit ce que j'avais à dire sur ce sujet, et si c'est pour que ma bonne foi soit remise en cause, je n'ai aucune envie de continuer cette discussion.

  13. #13
    Nouveau membre du Club
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2010
    Messages
    46
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2010
    Messages : 46
    Points : 32
    Points
    32

    Par défaut usage

    Un langage humain est créé par l'usage, il n'est pas imposé par des académiciens.

    Je pense qu'il devrait en être de même pour les langages informatiques, ça eu été comme disait Fernand Raynaud.
    On discute entre potes, et si une idée est bonne, elle est adoptée.

    L'académie peut prếcher qu'on a le droit de mettre des zonions dans les zaricots, mais si tout le monde trouve ça débile et moche, quel intérêt ?

    Je ne trouve aucune légitimité à Microsoft pour parler d'informatique.
    Microsoft a été sponsorisé par Rockfeller pour prendre le contrôle de l'IT.
    Bill Gates signe William H Gates III.
    Lui même fils de William H Gates II.
    Lui même fils de William H Gates I déjà pote avec le vieux Rockfeller.
    Il n'a jamais rien inventé dans son garage, surtout pas l'informatique ;-)

  14. #14
    SLE
    SLE est déconnecté
    Membre éclairé Avatar de SLE
    Homme Profil pro
    Consultant informatique
    Inscrit en
    janvier 2004
    Messages
    604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : janvier 2004
    Messages : 604
    Points : 799
    Points
    799

    Par défaut

    Dans l'exemple C# 8.0, quel est l'intérêt de déclarer un string? alors que le type string est déjà nullable par défaut ?

  15. #15
    Membre éprouvé Avatar de worm83
    Homme Profil pro
    Architecte technique
    Inscrit en
    février 2010
    Messages
    456
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Conseil

    Informations forums :
    Inscription : février 2010
    Messages : 456
    Points : 1 067
    Points
    1 067

    Par défaut

    Citation Envoyé par SLE Voir le message
    Dans l'exemple C# 8.0, quel est l'intérêt de déclarer un string? alors que le type string est déjà nullable par défaut ?
    Comme je l'ai dit précédemment :

    Le but n'est pas réellement de forcer les référence a ne plus être nullable, comme je l'ai compris dans ton papier (ce qui serait une hérésie), mais de forcer les développeur à vérifier le fait que celle-ci n'est pas "null".

    On force une programmation défensive en quelque sorte.
    "Le train de tes injures roule sur le rail de mon indifférence."

    "Monde de merde !!"

    Georges Abitbol.

  16. #16
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2004
    Messages : 19 829
    Points : 40 600
    Points
    40 600

    Par défaut

    Citation Envoyé par SLE Voir le message
    Dans l'exemple C# 8.0, quel est l'intérêt de déclarer un string? alors que le type string est déjà nullable par défaut ?
    Parce que string tout seul signifiera par défaut un string qui ne peut pas être null.

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

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 12 734
    Points : 22 867
    Points
    22 867

    Par défaut

    C'est valable que pour string ou pour toutes les classes ?
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  18. #18
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2004
    Messages : 19 829
    Points : 40 600
    Points
    40 600

    Par défaut

    Citation Envoyé par Pol63 Voir le message
    C'est valable que pour string ou pour toutes les classes ?
    Toutes les classes.

    Évidemment ce comportement sera optionnel, sinon ça pèterait tout le code existant...

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

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 12 734
    Points : 22 867
    Points
    22 867

    Par défaut

    Citation Envoyé par tomlev Voir le message
    Évidemment ce comportement sera optionnel, sinon ça pèterait tout le code existant...
    c'est l'info qui me manquait pour voir que ce n'était pas absurde
    comme quoi lire la source est souvent pratique ^^
    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