"tous les objets sont des objets" :-) Vu comme ca effectivement ...
Nan, je voulais juste dire que int etait un objet au meme titre qu'une Factory. Ce qui n'est pas le cas dans la plupart des autres langages objets où int est juste un type primitif ...
OK... Effectivement ton exemple de pile demontre bien l'utilite de la covariance pour pouvoir faire ce genre d'implementation.
Ceci dit, c'est vrai qu'en terme de conception pure, je prefere largement les containers generiques ... Pour moi ca a plus de sens.
La notation "Assiette element;" ne me convient pas trop non plus.
Sinon pour regler le probleme de la covariance il y a des techniques connues ?
Parce que finalement, j'ai l'impression que ca deporte le probleme d'un endroit a un autre.
Typiquement tu vas etre oblige (que ce soit le compilo ou l'utilisateur) de faire un check avant d'appeler la methode non ?
Exemple : (pseudo notation)
Animal a = Vache;
Vector<Nourriture> v;
v.push(Herbe); v.push(viande);
foreach i in v
{
a.mange(i);
}
Dans le cas de la covariance, il va bien falloir a un moment donne qu'il y ait un check du style :
if (i instanceof Herbe)
{
objets.mange(i);
}
else erreur // que ce soit une erreur dynamique ou de compilation
Dans le cas de la contravariance, le check repose il est vrai entierement sur le programmeur, ce qui est pas cool.
Donc, si tu me dis qu'il y a des solutions au probleme de check a la compilation je changerai bien Nosica pour l'inclure dedans...
Typiquement, quand on avait essaye de le mettre dans le langage, on avait ensuite l'analyse globale qui verifiait qu'on appelait pas de methodes "non definies".
Analyse des types possible de v ==> Viande, Herbe
Analyse des types possible de a ==> Vache
==> a{Vache}.mange(i{Viande, Herbe}) ==> Erreur de compilation
Je vois bien des algos qui permettent de determiner un sur ensemble des types possibles, mais pas l'ensemble stricte : je risque de detecter des erreurs qui n'existent pas...
Donc, quelles autres solutions ?
(a part le check au runtime bien sur ...)
[^] # Re: Nosicalight version 0.2
Posté par Epsos . En réponse au journal Nosicalight version 0.2. Évalué à 1.
Nan, je voulais juste dire que int etait un objet au meme titre qu'une Factory. Ce qui n'est pas le cas dans la plupart des autres langages objets où int est juste un type primitif ...
OK... Effectivement ton exemple de pile demontre bien l'utilite de la covariance pour pouvoir faire ce genre d'implementation.
Ceci dit, c'est vrai qu'en terme de conception pure, je prefere largement les containers generiques ... Pour moi ca a plus de sens.
La notation "Assiette element;" ne me convient pas trop non plus.
Sinon pour regler le probleme de la covariance il y a des techniques connues ?
Parce que finalement, j'ai l'impression que ca deporte le probleme d'un endroit a un autre.
Typiquement tu vas etre oblige (que ce soit le compilo ou l'utilisateur) de faire un check avant d'appeler la methode non ?
Exemple : (pseudo notation)
Animal a = Vache;
Vector<Nourriture> v;
v.push(Herbe); v.push(viande);
foreach i in v
{
a.mange(i);
}
Dans le cas de la covariance, il va bien falloir a un moment donne qu'il y ait un check du style :
Dans le cas de la contravariance, le check repose il est vrai entierement sur le programmeur, ce qui est pas cool.
Donc, si tu me dis qu'il y a des solutions au probleme de check a la compilation je changerai bien Nosica pour l'inclure dedans...
Typiquement, quand on avait essaye de le mettre dans le langage, on avait ensuite l'analyse globale qui verifiait qu'on appelait pas de methodes "non definies".
Analyse des types possible de v ==> Viande, Herbe
Analyse des types possible de a ==> Vache
==> a{Vache}.mange(i{Viande, Herbe}) ==> Erreur de compilation
Je vois bien des algos qui permettent de determiner un sur ensemble des types possibles, mais pas l'ensemble stricte : je risque de detecter des erreurs qui n'existent pas...
Donc, quelles autres solutions ?
(a part le check au runtime bien sur ...)
David