class Animal { foo(Nouriture) }
class Vache { foo(Herbe)}
Animal :> Vache et Nouriture :> Herbe d'ou covariance car le sens de :> est le meme
:> est le symbole du sous-typage. moyen memotechnique 1 : le sens de la flèche est inverse de celui des graphes UML. moyen memotechnique 2 : le sens est celui de l'intension (avec un s) c'est-a-dire le nombre d'instances (les instances de Vache sont aussi instances de Animal).
Contravariance (exemple pas réel car le monde réel ne l'est pas) :
class A { foo(Herbe) }
class B extend A { foo(Nouriture) }
On a A :> B mais Herbe <: Nouriture d'ou contravariance
Invariance
class Animal { foo(Nouriture) }
class Vache { foo(Nouriture) }
On a Animal :> Vache et Nouriture = Nouriture donc invariance
Euh, sinon mon avis sur nosica.
1) Eviter de faire la meme grosse erreur que Java : tableaux pas homogenes avec le reste du langage. les tableaux en java c'est ni un type primitif, ni un objet et en plus il est covariant (alors que le reste du langage ne l'est pas)
j'avais un exemple mais je le retrouve plus
2) Un truc qui est bien en general est d'unifier la syntaxe attribut / methode sans parametre.
ecrire a.foo au lieu de a.foo()
3) Eviter d'etre trop verbeux si l'objectif n'est pas de faire un langage de production (ada, eiffel)
Je veux dire ne pas devoir ecrire de choses redondantes ou de declarer des choses un peu inutiles
4) faire sauter le ; en fin d'instruction. c'est une honte de trainer encore ca.
5) avoir une reflection plus profonde pour que le langage ait quelque chose en plus. :)
[^] # Re: Nosicalight version 0.2
Posté par MrTout . En réponse au journal Nosicalight version 0.2. Évalué à 1.
class Animal { foo(Nouriture) }
class Vache { foo(Herbe)}
Animal :> Vache et Nouriture :> Herbe d'ou covariance car le sens de :> est le meme
:> est le symbole du sous-typage. moyen memotechnique 1 : le sens de la flèche est inverse de celui des graphes UML. moyen memotechnique 2 : le sens est celui de l'intension (avec un s) c'est-a-dire le nombre d'instances (les instances de Vache sont aussi instances de Animal).
Contravariance (exemple pas réel car le monde réel ne l'est pas) :
class A { foo(Herbe) }
class B extend A { foo(Nouriture) }
On a A :> B mais Herbe <: Nouriture d'ou contravariance
Invariance
class Animal { foo(Nouriture) }
class Vache { foo(Nouriture) }
On a Animal :> Vache et Nouriture = Nouriture donc invariance
Euh, sinon mon avis sur nosica.
1) Eviter de faire la meme grosse erreur que Java : tableaux pas homogenes avec le reste du langage. les tableaux en java c'est ni un type primitif, ni un objet et en plus il est covariant (alors que le reste du langage ne l'est pas)
j'avais un exemple mais je le retrouve plus
2) Un truc qui est bien en general est d'unifier la syntaxe attribut / methode sans parametre.
ecrire a.foo au lieu de a.foo()
3) Eviter d'etre trop verbeux si l'objectif n'est pas de faire un langage de production (ada, eiffel)
Je veux dire ne pas devoir ecrire de choses redondantes ou de declarer des choses un peu inutiles
4) faire sauter le ; en fin d'instruction. c'est une honte de trainer encore ca.
5) avoir une reflection plus profonde pour que le langage ait quelque chose en plus. :)