il n'y a pas de pourquoi ... juste des comments
OK, je vais formuler autrement :
- syntaxe simple pour la lisibilite/maintenance du code
- syntaxe que je trouve manquer a Java, parceque sinon il y a des pattern qui ne sont pas implementables et reutilisables (ex : la factory qu'il faut reimplementer from scratch en Java)
- covariance sur tous les parametres parce que ca permet de rendre le langage plus sur en limitant les cast, parce que ca permet d'implementer du double dispatch sans passer par un visiteur, donc plus efficace, plus lisible, plus sur et plus maintenable ...
- pas de type predefinis car il arrive qu'on ait besoin de modifier l'interface d'un type simple. Or souvent ce type est dans le compilo, donc read-only. Pas en Nosica. Et je te rassure ca marche plutot bien sans etre rock and roll : ca permet au contraire beaucoup de souplesse. Actuellement les seuls types vraiment codes en dur dans Nosica sont : Object, None, et Array.
La raison de base pour laquelle les opérateurs sont surchargeables n'est ainsi pas lisible
Tout a fait d'accord avec toi. Il faut donc que je fasse une passe sur la doc pour rajouter le pourquoi de chaque feature. Deja, est ce que mon blob precedent te convient ?
Pour info la surcharge sur le type retour marche tres tres bien. Une ancienne version la gerait tres bien. Malheureusement ca avait comme (mauvaises) consequences :
- complexification du code du compilo (je pense que 30% du code du typechecker lui etait dedie)
- reporting d'erreur illisible : presentation de toutes les branches d'executions possible en disant : desole pas de match, ou desole trop de match.
- comprehension parfois difficile pour le programmeur : pas quel chemin se fait l'execution de f().g().h() ?
Pas du tout ! Avec l'expérience, on constate que les objets retournés par une méthode sont en général utilisés ailleurs, et que si plusieurs valeurs doivent être retournées par une seule méthode, c'est peut-être parce qu'elles font partie d'un même objet, qu'on n'a pas encore vu, et qu'il serait intelligent de fournir.
D'accord avec toi sur certains cas. Mon experience a moi me dit que ce n'est pas la majorite des cas. La solution de prendre des parametres en E/S alors que le parametre est vraiment en sortie est bancale. (necessite de doc, pas de check par le compilo du bon usage de la methode). Voir la thread http://www.nosica.net/forum/viewtopic.php?t=58&start=15(...) Tu verras qu'au départ j'étais contre cette feature. Et finalement ca le fait bien.
[^] # Re: Je prefere Netbeans.
Posté par Epsos . En réponse à la dépêche Eclipse compilé en natif.. Évalué à 3.
OK, je vais formuler autrement :
- syntaxe simple pour la lisibilite/maintenance du code
- syntaxe que je trouve manquer a Java, parceque sinon il y a des pattern qui ne sont pas implementables et reutilisables (ex : la factory qu'il faut reimplementer from scratch en Java)
- covariance sur tous les parametres parce que ca permet de rendre le langage plus sur en limitant les cast, parce que ca permet d'implementer du double dispatch sans passer par un visiteur, donc plus efficace, plus lisible, plus sur et plus maintenable ...
- pas de type predefinis car il arrive qu'on ait besoin de modifier l'interface d'un type simple. Or souvent ce type est dans le compilo, donc read-only. Pas en Nosica. Et je te rassure ca marche plutot bien sans etre rock and roll : ca permet au contraire beaucoup de souplesse. Actuellement les seuls types vraiment codes en dur dans Nosica sont : Object, None, et Array.
La raison de base pour laquelle les opérateurs sont surchargeables n'est ainsi pas lisible
Tout a fait d'accord avec toi. Il faut donc que je fasse une passe sur la doc pour rajouter le pourquoi de chaque feature. Deja, est ce que mon blob precedent te convient ?
Pour info la surcharge sur le type retour marche tres tres bien. Une ancienne version la gerait tres bien. Malheureusement ca avait comme (mauvaises) consequences :
- complexification du code du compilo (je pense que 30% du code du typechecker lui etait dedie)
- reporting d'erreur illisible : presentation de toutes les branches d'executions possible en disant : desole pas de match, ou desole trop de match.
- comprehension parfois difficile pour le programmeur : pas quel chemin se fait l'execution de f().g().h() ?
Pas du tout ! Avec l'expérience, on constate que les objets retournés par une méthode sont en général utilisés ailleurs, et que si plusieurs valeurs doivent être retournées par une seule méthode, c'est peut-être parce qu'elles font partie d'un même objet, qu'on n'a pas encore vu, et qu'il serait intelligent de fournir.
D'accord avec toi sur certains cas. Mon experience a moi me dit que ce n'est pas la majorite des cas. La solution de prendre des parametres en E/S alors que le parametre est vraiment en sortie est bancale. (necessite de doc, pas de check par le compilo du bon usage de la methode). Voir la thread http://www.nosica.net/forum/viewtopic.php?t=58&start=15(...) Tu verras qu'au départ j'étais contre cette feature. Et finalement ca le fait bien.