Discussion :

[Christophe Genolini]

5 Langage objet

5.1 Héritage multiple

Il doit être possible. Par exemple, vecteurInteger doit hériter de la classe abstraite vecteur et de integer. On peut instaurer un ordre prioritaire : pere1, pere2, grand-Pere11,

5.2 Méthodes de méthode

Ajouter des méthodes de méthodes. L’une d’entre elle serait VoirPseudoCode() ; L’autre VoirCode().
Une solution possible serait de définir une classe qui contiendrait les noms de toutes les méthodes possible et qui aurait elle-même la méthode voirCode()

5.3 This

En java, this dans un constructeur permet d’appeler un autre constructeur de la même classe. Par contre, il y a une restriction, une telle utilisation ne peut se faire qu’en première ligne du nouveau constructeur. Dans R++, il faudra lever cette contrainte et éventuellement autoriser un appel vers le constructeur depuis n’importe quelle méthode ?

5.4 This, bis

Autorise-t-on le travaille sur les champs sans this, ou pas ?

5.5 Nomenclature

Interdiction d’avoir un argument de méthode qui a le même nom qu’un champ de la classe (c’est autorisé en java !!!)

5.6 Accès

Accéder à un objet, c’est accéder à tous ses champs

5.7 Surcharge

Interdite, SAUF pour les constructeurs. Par contre, l’ordre des arguments ne devra pas permettre de faire des constructeurs différents : on ne pourra pas avoir un constructeur (int,char) et un autre (char,int).
Quelque soit notre décision sur une éventuelle promotion automatique, il ne faut pas qu’elle vienne interférer avec les constructeurs.

[haddad_malek]

5 Langage objet
5.1 Héritage multiple
Les classes abstraites existent en Java mais pas en R (qui a, en revanche, la notion de classes virtuelles qui ne permettent pas de créer un objet -utiliser le new-). la Classe Vector existe en java et n'est pas abstraite.

L'héritage multiple n'existe pas en java (mais par utilisation des interfaces, on s'en approche), mais en R oui, même si son utilisation est déconseillée.

Attention le fait de pouvoir utiliser l'héritage impose quelques considérations :

Exemple (à tester avec R) qui fonctionne avec Java :

Soit A une classe et B une sous-classe de A.
On peut parfaitement avoir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
A v1      =       new B() ;
B v2 = (B) v1 ; // parfaitement licite, pas de problème à l'exécution
A v3     =  new A() ;
B v4 = (B) v3 ; // pas de pb à la compilation mais pb à l'exécution …

Java n'est pas entièrement typé à la compilation, certaines choses sont vérifiées seulement à l'exécution
Le typage, l'héritage, la conversion sont étroitement liés en java, il faut donc regarder dans le détail ce qu'on peut/doit faire dans le cas de R++.

5.2 Méthodes de méthode
Je ne connais pas de langage objet "classique" qui possède cela (sinon avec Java, on peut utiliser l'introspection). Ou alors au travers d'environnement associé (Eclipse, Rstudio …). En Java, on peut utiliser l'introspection pour s'en rapprocher.

5.3 This
L'utilisation de this dans le cas présenté est assez rare et se rapproche de C++, this est plus employé pour désigner
les champs de l'instance utilisée (initialisations). Pour moi les 2 utilisations ne sont pas nécessaires et je ne comprends pas ce que veut dire l'autorisation d'appel d'un constructeur depuis une méthode quelconque :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
new ClassT(... ) crée l'objet n'est-ce pas suffisant ?
new ClassT(...) peut-être passé comme argument à une méthode (c'est un objet !)

ou passer par une création explicite (ClassT t = new ClassT(...) ; maMethode(t, ...)).
Il est vrai que cela dépend de la qualification du constructeur -en principe public- et de l'endroit où se trouve la méthode en question (classe héritant d'une autre ou pas).

5.5 Nomenclature
En quoi cela pose t-il un problème ?

5.6 Accès
C'est donc différent de java, où on peut créer des «setteurs» et des «getteurs» pour l'accès aux champs* d'une façon différenciée.
Mais alors comment accéder aux différents champs (nom qualifié ? ) dans ce que tu proposes ?

5.7 Surcharge
'D'après moi la "surchage" (overloading) dans une classe, est effectivement à éviter mais l'"overriding" est très utile
pour spécialiser une méthode déclarée dans la superclasse.