Pour avoir suivi pas mal de discussions entre D. Colnet (papa de SmartEiffel) et B. Sonntag (papa de Lisaac) qui sont évidemment tout à fait solide sur le lambda calcul et la sureté de type vu que c'est leur domaine de recherche, il ressort plusieurs choses :
- On ne sait pas faire de type-safe propre avec de l'objet, parce qu'algébriquement ça cadre mal (pour les détails faut leur demander, j'aurai beaucoup de mal à l'expliquer) avec la notion d'instance ou de clonage.
- Java est bourré de trous dans l'implem des génériques
- Java est un langage qui accepte le cast. Or, désolé, mais le cast, c'est tout sauf type-safe.
- Java possède le type Null, qui est par essence pas type-safe
- Java est covariant, et malheureusement, ce n'est pas type-safe non plus. Si tu veux vraiment l'être, il faut être invariant, car, à moins d'une analyse de flot très profonde sur une fermeture transitive totale du code, tu ne peux pas avoir l'assurance que tu n'auras pas de problèmes. Or, Java, c'est de la compilation séparée. Sans compter l'introspection, où tu ne peux rien savoir.
Regarde le modèle objet de OCaML, là c'est simple, c'est invariant. L'héritage est réduit à sa plus simple expression de ne pas recopier le code, mais lorsqu'il s'agit de mettre B là où il attend A, même si B hérite de A, le compilateur te jette tout de suite !
Bref, Java est un peu type-safe. Les NullPointerException et les ClassCastExceptions quotidiens sont là pour le prouver.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Encore le type Null...
Posté par Ontologia (site web personnel) . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 3.
Pour avoir suivi pas mal de discussions entre D. Colnet (papa de SmartEiffel) et B. Sonntag (papa de Lisaac) qui sont évidemment tout à fait solide sur le lambda calcul et la sureté de type vu que c'est leur domaine de recherche, il ressort plusieurs choses :
- On ne sait pas faire de type-safe propre avec de l'objet, parce qu'algébriquement ça cadre mal (pour les détails faut leur demander, j'aurai beaucoup de mal à l'expliquer) avec la notion d'instance ou de clonage.
- Java est bourré de trous dans l'implem des génériques
- Java est un langage qui accepte le cast. Or, désolé, mais le cast, c'est tout sauf type-safe.
- Java possède le type Null, qui est par essence pas type-safe
- Java est covariant, et malheureusement, ce n'est pas type-safe non plus. Si tu veux vraiment l'être, il faut être invariant, car, à moins d'une analyse de flot très profonde sur une fermeture transitive totale du code, tu ne peux pas avoir l'assurance que tu n'auras pas de problèmes. Or, Java, c'est de la compilation séparée. Sans compter l'introspection, où tu ne peux rien savoir.
Regarde le modèle objet de OCaML, là c'est simple, c'est invariant. L'héritage est réduit à sa plus simple expression de ne pas recopier le code, mais lorsqu'il s'agit de mettre B là où il attend A, même si B hérite de A, le compilateur te jette tout de suite !
Bref, Java est un peu type-safe. Les NullPointerException et les ClassCastExceptions quotidiens sont là pour le prouver.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker