hibOu :
Je me suis un peu plus penché sur ton projet. J'ai regarder les sources, je suis même aller jusqu'à chercher d'autre "java2c" sur le net (Y'avais pas grand chose d'interessant à part p-e gcc-java (encore un gcc !) et un "jcc" dont je n'est pas reussi à avoir les sources). Et en fait j'ai été étonné qu'il n'y ait pas la fonctionnalité principale d'un langage OO qui est le polymorphisme : dommage.
//Une String est un Object
Object o = new String("Hello");
//Méthode surchargée
System.print("hello");
System.print(2345);
System.print(o);
String s = "toto";
if (o.equals(s)) { //O est un Object pour le compilateur, pourtant en runtime, la méthode de la classe String est invoquée ...
}
Captioned a = new Button(); // Captionned est une Interface
Captioned b = new Frame();
b.setCaption(s.toString()); // La méthode de la bonne classe est invoquée ... Button et Frame sont dans 2 branches différentes de la hiérarchie - Si ce n'est pas du polymorphisme ...
etc .
hibOu :
Puis j'ai essayer d'imaginer comment j'aurais fait en java-moka un de mes programme que j'ai actuellement codé en C.
Et en fait je me suis rendu compte que pour la Ti, il faut en général à un moment où à un autre un accès direct à la mémoire, soit pour dessiner rapidement, soit pour écrire dans un fichier. Je me vois pas utiliser des outputstream sur une Ti...
native.DrawLine ( 0, 0, 15, 15 , A_NORMAL );
hibOu :
Donc le java me parait finalement assez inapproprié. Je pense que de l'objet pour la Ti devrai plus ressembler à du C++.
hibOu :
Mais j'ai vu qu'il y avait la possibilité de faire des native{....} : est-ce la solution ?
hibOu :
D'ailleurs je n'ai pas reussi à savoir comment sont reliées les variables internes au native et les variables du programme écrit en java-moka : par exemple, pour les paramètres d'une fonction native.
native.DrawLine ( 0, 0, 15, 15 , A_NORMAL );
DrawLine ( 0, 0, 15, 15 , A_NORMAL );
int toto;
long int toto;
Quesoft :
En fait, Moka supporte le polymorphisme des méthodes et des objets. La seule limitation est que la signature d'un message est générée à la compilation et non à l'exécution (beaucoup plus rapide, mais beaucoup moins cool). Je vois mal comment on peut affirmer que Moka ne supporte pas le polymorphisme. Sans polymorphisme, explique ça :
//Une String est un Object Object o = new String("Hello"); //Méthode surchargée System.print("hello"); System.print(2345); System.print(o); String s = "toto"; if (o.equals(s)) { //O est un Object pour le compilateur, pourtant en runtime, la méthode de la classe String est invoquée ... } Captioned a = new Button(); // Captionned est une Interface Captioned b = new Frame(); b.setCaption(s.toString()); // La méthode de la bonne classe est invoquée ... // Button et Frame sont dans 2 branches différentes de la hiérarchie - Si ce n'est pas du polymorphisme ... etc .
Object s = new String("blabla");
System.out.println(s); //appelera println(String) et non println(Object)
hibOu :
Puis j'ai essayer d'imaginer comment j'aurais fait en java-moka un de mes programme que j'ai actuellement codé en C.
Et en fait je me suis rendu compte que pour la Ti, il faut en général à un moment où à un autre un accès direct à la mémoire, soit pour dessiner rapidement, soit pour écrire dans un fichier. Je me vois pas utiliser des outputstream sur une Ti...
Utilise la classe moka.io.Graph qui est essentiellement un mapping des fonctions de Graph.h ou l'interopérabilité (permet de faire presque tout ce que l'on fait en C en Moka et essentiel à l'heure actuelle pour utiliser les fonction de vat.h - si qqn est intéressé à réimplémenter moka.io.File avec les fonctions de vat.h à la place de stdio.h, qu'il ne se gêne pas ... je devrai le faire un jour - parce qu'à d'autres endroits de l'API je l'utilise anyway) :
native.DrawLine ( 0, 0, 15, 15 , A_NORMAL );
c clair, mais je trouve que c'est tout l'interet du langage objethibOu :
Donc le java me parait finalement assez inapproprié. Je pense que de l'objet pour la Ti devrai plus ressembler à du C++.
Moka est assez proche de ce que serait une implémentation minimale du C++, sans la surcharge des opérateurs et avec un look-and-feel Java. Il est beaucoup plus léger que ces deux langages (mais moins puissant cependant). Je ne vois pas pourquoi un C++ 'light' serait nécessairement plus adapté aux TI68K que le Moka.
Évidemment, tout le monde a des goûts différents et le C++ est un langage très répendu. Je serais le premier à être content de voir un compilateur C++ viable apparaître pour les TI, mais je serais surpris qu'il soit moins lourd que Moka (là je ne parle pas de l'API, juste du langage - les programmes en C++ utilisent beaucoup de fonctions des libs standards du C, ce qui plus performant que de programmer en objet).
S'il implémente des features comme du polymorphisme pur à 100 % (i.e. que la signature du message est déterminé en runtime), alors il génèrera nécessairement des progs plus gros et moins rapides.
hibOu :
en fait, j'appelle plutot cela de la surcharge. Mais on peut aussi appeler ca du polymorphisme (ad-hoc).
En fait, je sais plus trop comment s'appelle la fonctionnalité suivante :Object s = new String("blabla"); System.out.println(s); //appelera println(String) et non println(Object)
Et ça je trouve que c'est l'essentiel d'un langage Objet. Sans ça, je ne trouve que le langage ne devient qu'il simple surcouche syntaxique au C.
Pollux
:hibOu :
en fait, j'appelle plutot cela de la surcharge. Mais on peut aussi appeler ca du polymorphisme (ad-hoc).
En fait, je sais plus trop comment s'appelle la fonctionnalité suivante :Object s = new String("blabla"); System.out.println(s); //appelera println(String) et non println(Object)
Et ça je trouve que c'est l'essentiel d'un langage Objet. Sans ça, je ne trouve que le langage ne devient qu'il simple surcouche syntaxique au C.
Fonction virtuelle ? En tout cas ça reste toujours dans le genre surcouche syntaxique... (y a juste un pointeur vers la virtual function table dans chaque instance de la classe)
print(String); print(int);
print_String(String); print_int(int);
Object s = new String("blabla");
System.out.println(s); //appelera println(String) et non println(Object)
hibOu :
Et ça je trouve que c'est l'essentiel d'un langage Objet.
Sans ça, je ne trouve que le langage ne devient qu'il simple surcouche syntaxique au C.
int i = vec.get(); String = vec.get();
hibOu :
Et pour créer un fichier ? Une fois j'avais utilisé fopen, fread.... pour faire de la compression de fichier et c'était vraiment lent... alors qu'il est très simple d'écrire directement dans la mémoire. Sans pointeur, je ne demande bien comment faire....
private static char[] returnToken (char[] str, char[] buf) {
//TAB, NL, FF, CR, SPACE
char[] delim = {9, 10, 12, 13, 32};
int len = native.strlen(str);
int end;
int i;
int n;
char* pos = str;
while (*pos != '\0') {
for (i = 0; i < 5; i++) {
if (*pos == delim[i]) {
break;
}
}
if (i == 5) {
break;
}
pos ++;
}
str = pos;
while (*pos != '\0') {
for (i = 0; i < 5; i++) {
if (*pos == delim[i]) {
break;
}
}
if (i < 5) {
break;
}
pos ++;
}
end = (int)(pos - str) ;
native.memcpy(buf, str, end);
buf[end] = '\0';
return pos;
}
hibOu :
Pour le lien tardif, il faut ajouter le code de l'appel de cette "virtual function table"
Je n'en savais pas la traduction, j'avais traduit ça 'résolution dynamique des méthodes'. Moka fait du dynamic binding, sans ça l'exemple avec les objets qui interfacent Captioned ne fonctionnerais pas ...
Object s = new String("blabla");
System.out.println(s); //appelera println(String) et non println(Object)
Object s = new String("blabla");
s.print(); //Pour cela, il faut que la superclasse ait une méthode print
Pour le lien tardif, il faut ajouter le code de l'appel de cette "virtual function table"
Quesoft :
Moi, j'aimes les compromis des langages typés et, bien que je trouve dommage que Moka ne supporte pas le type de polymorphisme dont tu parlais, je crois que c'était essentiel pour avoir quelque chose de viable sur calculatrice.
hibOu :
Et pour créer un fichier ? Une fois j'avais utilisé fopen, fread.... pour faire de la compression de fichier et c'était vraiment lent... alors qu'il est très simple d'écrire directement dans la mémoire. Sans pointeur, je ne demande bien comment faire....
Besoin de pointeurs ? Moka ne retourne pas d'erreur de syntaxe lorsqu'on les utilises :private static char[] returnToken (char[] str, char[] buf) { //TAB, NL, FF, CR, SPACE char[] delim = {9, 10, 12, 13, 32}; int len = native.strlen(str); int end; int i; int n; char* pos = str; while (*pos != '\0') { for (i = 0; i < 5; i++) { if (*pos == delim[i]) { break; } } if (i == 5) { break; } pos ++; } str = pos; while (*pos != '\0') { for (i = 0; i < 5; i++) { if (*pos == delim[i]) { break; } } if (i < 5) { break; } pos ++; } end = (int)(pos - str) ; native.memcpy(buf, str, end); buf[end] = '\0'; return pos; }
Pour le reste (les fonctions de vat.h) tu mets tout dans un bloc ou une méthode native et tu fais comme en C...
il faudrait alors répondre à ces personnes qu'elles devraient faire du C !
Là, j'en connais certains qui me critiquerais si j'implémentais ce truc ...
hibOu :
ha, il y a des pointeurs.
Ca ressemble déjà moins au java. D'ailleurs, ca cause pas des pb lors de la génération de la javadoc ?
hibOu :
il faudrait alors répondre à ces personnes qu'elles devraient faire du C !
Oui, mais je voulais un langage utilisable en pratique, alors c'est pourquoi j'ai fais ces choix là ...
hibOu :
Je comprend mieux ton projet. A mon avis tu devrais cependant éviter une trop grande comparaison à java. Il faudrait juste énoncé le fait que tu t'en inspires.
hibOu :
Je vais p-ê me mettre un peu à moka alors, pour essayer
Kevin Kofler :
Et si tu faisais comme en C++, c'est-à-dire qu'il faut marquer explicitement les fonctions virtual pour avoir du polymorphisme dynamique?
Personne p = new Personne("Nom personne");
Personne g = new GrandPere("Nom GP");
//Au lieu de faire :
MaClasse.afficher(g); //Qui est surchargée pour traiter et les GP et les personnes
//On peut faire :
g.afficher(); // Qui est une méthode de la superclasse Personne overridée par la classe GrandPere
Pollux :
Honnêtement si tu veux que Moka soit plus utile pour faire des gros projets, tu devrais piquer quelques idées au C++ : par exemple, le fait de pouvoir libérer automatiquement un objet dès qu'il n'est plus visible serait très utile et éviterait que les programmes Moka aient d'énormes leaks de mémoire... (mais évidemment ça reste délicat, il faut employer des références dans certains cas, etc...)
TTruc t;
TTruc *t = new TTruc();
char *t = "world";
{
string s = (string)"hello "+t;
cout << s;
}
char *t = "world";
{
string s,hello;
String::new_from_charptr(&hello,"hello ");
String::concat_with_charptr(&s,&hello,t);
String::delete(&hello);
ostream::append_string(&cout,&s);
String::delete(&s);
}
Godzil :
Sachant que MOKA genere du C, suivant comment il définit les variables de type "objets" si ils sont défini localement a une procedure, il seront détruit comme le C le fait. Apres ça dépend comment il représente les objets.
//Je déclare un Object o avec un scope déterminé, ce serait traduit par quelque chose de semblable : TObject mem; //Mon emplacement mémoire TObject *o = &mem;//J'ai une référence vers l'objet - transparent pour l'utilisateur. //Quand on initialise o - o = new Object() initTObject(o); //Fonction fictive qui initialiserait l'objet
Pollux :
Si si on peut redéfinir une méthode non virtuelle ^^
MaClasse *o = new MaSousClasse(); //Pour le compilateur, o est un MaClasse, alors qu'en runtime, o se révèle être un MaSousClasse. o.m(); //Lien statique : la méthode de MaClasse est invoquée.
MaClasse o = new MaSousClasse(); //Pour le compilateur, o est un MaClasse, alors qu'en runtime, o se révèle être un MaSousClasse. o.m(); //Lien dynamique: la méthode de MaSousClasse est invoquée.
Kevin Kofler :
Donc il y a déjà du polymorphisme dynamique, comme en Java. C'est juste la surcharge qui ne le gère pas, et là, franchement, je ne suis pas sûr de quelle manière ce soit géré en C++ et en Java.
//o.maMethode() est traduit : o->maMethode_(o);
//o.maMethode() est traduit : MonInterface_maMethode_(o);
Kevin Kofler :
Je ne pense pas qu'il y ait un runtime dispatch pour le surchargement en C++, donc je pense que c'est comme en Moka.
Object s = new String("blabla");
System.out->println(s); //appelera println(Object) au lieu de println(Object)
Object s = new String(); s.clone(); // appel de String.clone() et non Object.clone()
Quesoft
:Kevin Kofler :
Donc il y a déjà du polymorphisme dynamique, comme en Java. C'est juste la surcharge qui ne le gère pas, et là, franchement, je ne suis pas sûr de quelle manière ce soit géré en C++ et en Java.
Un runtime dispatch (je crois qu'Objective C fait ça), j'ai peur que ce soit vraiment peu performant. En Moka, un appel de méthode ce fait comme ça :
//o.maMethode() est traduit : o->maMethode_(o);
Vous comprendrez que le membre maMethode_ pointe vers une fonction. En théoriePour supporter le runtime dispatch il faudrait que je fasse quelque chose de semblable à ce que je fais avec les interfaces :
//o.maMethode() est traduit : MonInterface_maMethode_(o);
La fonction MonInterface_maMethode_() contient du code pour retrouver la bonne fonction p/r à la classe de o. C'est moins rapide que dans le premier cas par contre (mais pas trop lent car les pointeurs sont stoké en mémoire et retrouvés avec un index que l'objet connait).
struct st_Fonctions_Objects {
Object * (*clone) (Object *) = &clone_Objects;
} Fonctions_Objects;
struct st_Fonctions_ClasseMachin { //classe machin hérite de Object
Object * (*clone) (Object *) = &clone_Objects; //si il n'y a pas de redéfinition
void ( * fonction_truc) (ClasseMahin *) = &fonction_truc_ClasseMachin;
} Fonctions_ClasseMachin;
ClasseMachin c = new ClasseMachin(); c.clone();traduit en :
ClasseMachin * c = malloc(....); Fonctions_ClasseMachin->clone(c);
public class test {
public static void main(String[] args) {
test t = new test();
Object o = new String ();
t.f(new String());
t.f(o);
}
void f(Object o) {
System.out.println("obj");
}
void f(String s) {
System.out.println("str");
}
}
str obj
hibOu :et ca sort : [pre] str obj
hibOu :
A mon avis, y'a plus simple que de faire une recherche.
Faudrait créer des structure en global :struct st_Fonctions_Objects { Object * (*clone) (Object *) = &clone_Objects; } Fonctions_Objects; struct st_Fonctions_ClasseMachin { //classe machin hérite de Object Object * (*clone) (Object *) = &clone_Objects; //si il n'y a pas de redéfinition void ( * fonction_truc) (ClasseMahin *) = &fonction_truc_ClasseMachin; } Fonctions_ClasseMachin;
et après tous les appels se feront par :ClasseMachin c = new ClasseMachin(); c.clone();traduit en :ClasseMachin * c = malloc(....); Fonctions_ClasseMachin->clone(c);
ClasseMachin c = new ClasseMachin(); c.clone();traduit en :
TClasseMachin * c = TClasseMachin_(); // où TClasseMachin est le type de la structure et TClasseMachin_() un constructeur qui retourne un ClasseMachin alloué et initialisé c->clone_(c);
typedef struct {
//Methode 1
//Methode de MonInterface
} TClasseA;
typedef struct {
//Methode 1
//Méthode 2
//Methode de MonInterface
} TClasseMachin;
ClasseA a = new ClasseA(); ClasseMachin c= new ClasseMachin (); MonInterface iA = a; MonInterface iC = c; a.methodeInter(); //Ok, je sais où est mon pointeur (pos 2) c.methodeInter(); //Ok, je sais où est mon pointeur (pos 3) iA.methodeInter();//Où est le pointeur ? (dépend du type de iA en cours d’exécution)
Quesoft :ClasseA a = new ClasseA(); ClasseMachin c= new ClasseMachin (); MonInterface iA = a; MonInterface iC = c; a.methodeInter(); //Ok, je sais où est mon pointeur (pos 2) c.methodeInter(); //Ok, je sais où est mon pointeur (pos 3) iA.methodeInter();//Où est le pointeur ? (dépend du type de iA en cours d’exécution)
C’est pour cela que j’ai implémenté la recherche pour les cas d'interface (qui est pas trop lente quand même).
struct st_Fonctions_Objects {
Object * (*clone) (Object *) = &clone_Objects;
char * (*toString) (Object *) = &toString_Objects;
} Fonctions_Objects;
struct st_Fonctions_ClasseMachin { //classe machin hérite de Object
Object * (*clone) (Object *) = &clone_Objects; //si il n'y a pas de redéfinition
char * (*toString) (Object *) = &toString_ClasseMachin; //il y a une redéfinition
void ( * fonction_truc) (ClasseMahin *) = &fonction_truc_ClasseMachin;
} Fonctions_ClasseMachin;
struct ClasseMachin {
st_Fonction_ClasseMachin * tab_fonctions;
....attributs...
}
ClasseMachin c = new ClasseMachin(); .... c.clone();traduit en :
ClasseMachin * c = malloc(....); c->tab_fonctions = &Fonctions_ClasseMachin; .... c->tab_fonctions->clone(c);
Objet c = new ClasseMachin(); .... c.clone();se traduit aussi par
Objet * c = malloc(....); c->tab_fonctions = &Fonctions_Objet; .... c->tab_fonctions->clone(c);
public class test {
public static void main(String[] args) {
test t = new test();
Object o = new String ();
t.f(new String());
t.f(o);
}
void f(Object o) {
System.out.println("obj");
}
void f(String s) {
System.out.println("str");
}
}
hibOu :
Note que ici Objet peut être une interface.
Et aussi, l'intanceof pourra se résumer à la comparaison des "tab_fonction"
ClasseA a = new ClasseA(); ClasseMachin c= new ClasseMachin (); MonInterface iA = a; MonInterface iC = c; iA.methodeInter();//Où est le pointeur ?
iA->tab_fonctions->methodeInter(iA);
BOOL instanceof ( TObject * object, TObject * prototype ) {
BOOL result = FALSE ;
while ( ( object != NULL ) && ! result ) { //Évidemment, le membre super de Object, superclasse de toutes les autres classes est NULL
if ( object -> class_id == prototype->class_id ) { //Chaque classe a un id unique attribué séquentiellement
result = TRUE ;
}
object = object -> super ; //ici, on a un pointeur vers un 'prototype' de la superclasse de l'objet en question
}
return result ;
}
BOOL instanceof ( TObject * object, TObject * prototype ) {
while ( object ) {
if ( object -> class_id == prototype -> class_id ) {
return TRUE ;
}
object = object -> super ;
}
return FALSE ;
}
squalyl^2 :
String hérite de Object, donc l'Object créé est initialisé avec l'héritage du new String() vu comme un Object
Mais il est déclaré en tant qu' Object. Donc il en ressort un Object, qui appelle la méthode demandant un Object.
normal nan?
Godzil :
Squalyl: oui dans un environement compilé c'est ce qui se passera, dans un environement interpreté, on peut savoir quel est le type reel de o