• [^] # Re: Encore le type Null...

    Posté par (site web personnel) . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 4.

    Alors deux choses :

    • En ce qui me concerne, je pense, comme Anthony Hoare, que le type Null ne doit pas exister dans le langage. Point. Foin de NULL_NOT_INITIALIZED, NULL_NOT_FOUND, NULL_REMOVED. Si tu veux gérer ce genre de cas, tu créés un type Somme : 
      type probleme = 
| NULL_NOT_INITIALIZED
| NULL_NOT_FOUND
| NULL_REMOVED
    • Les contraintes strictes sur les types est un sujet très intéressants et peu défriché. En fait tu l'as à haut niveau en OCaML/haskell, et à bas niveau avec des langage comme Esterel, etc... En OCaML/haskell, tu peux faire du type somme, du polymorphisme, bref des types algébriques assez poussé. En Esterel, tu peux mettre des contraintes sur tes entiers, mais Esterel, c'est fait pour du circuit logique (des processeurs quoi).

    Bref, ya pa encore de langage qui le gère sur toute la longueur du problème.

    En C++ avec les templates, tu peux faire pas mal de choses. Le gros problème de C++, c'est que la sémantique étant catastrophiquement bloatware, et que (donc) le compilateur étant basé sur de la compilation séparé, il est absolument impossible de faire une analyse de flot sur la totalité de ton code pour exporter les contraintes de tes types.
    En d'autres terme, le gros problème de C++/Template c'est que le compilo va checker ce qu'il peut checker avec les valeurs en dures qu'il trouve dans le code.
    S'il n'en trouve pas, ton code est pas testé, et ça plante au runtime, comme les autres.

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker