Que devient la programmation OO ? - Page 6

Quesoft
:

hibOu :
Note que ici Objet peut être une interface.
Et aussi, l'intanceof pourra se résumer à la comparaison des "tab_fonction"

On a le même problème avec les interfaces cependant :

ClasseA a = new  ClasseA();
ClasseMachin c= new  ClasseMachin ();
MonInterface iA = a;
MonInterface iC = c;

iA.methodeInter();//Où est le pointeur ?

Le copilateur traduirait :

iA->tab_fonctions->methodeInter(iA);

tab_fonction pointe au bon endroit (i.e. la table des fonctions de ClasseA) cependant, le compilateur la voit comme une structure st_Fonctions_MonInteface. Ça cause un problème si, par exemple, la classe ClasseA définit d'autres méthodes avant celle de l'interface, car ce seront celles-ci qui seront exécutés.

si ca marche mais a condition que les structures soient organisée de la même manière.

st_interface {
  fct1();
  fct2();
}
st_classe_implements_interface {
  fct1();  //obligatoirement la premiere
  fct2();  // idem
//.... puis ici toute les fonctions en plus
}


//Ne pas faire :
st_classe_implements_interface {
  fct_en_plus();
  fct2();  // idem
  fct1();  //obligatoirement la premiere
}

Sasume :
Oui, mais le polymorphisme aurait pu être poussé plus loin et considérer le vrai type de o (c'est-à-dire String) pour savoir quelle routine appeler.
Cela dit, je ne sais pas si ça ne risquerait pas de poser problème...

En fait, la question est : si on a une classe PointColoré qui hérite d'une classe Point, et si on a :

class truc {
  void f(Point p , PointColore pc);
  void f(PointColore pc , Point p);
}

que faire de l'appel ?

Point p = new Point();
f(p,p);

Je viens de tester avec java 1.4 : il refuse de compiler
Il ne veut pas compiler non plus :

Point p = new Point();
Point pc = new PointColore();
f(p,pc);

Le polymorphisme dynamique n'est pas toujours déterministe... donc c'est pas plus mal qu'il n'y en ait pas.

En fait, la question est : si on a une classe PointColoré qui hérite d'une classe Point, et si on a :

class truc { void f(Point p , PointColore pc); void f(PointColore pc , Point p); }


que faire de l'appel ?

Point p = new Point(); f(p,p);


ca compile pas, faut faire un cast

squalyl :
En fait, la question est : si on a une classe PointColoré qui hérite d'une classe Point, et si on a :

class truc { void f(Point p , PointColore pc); void f(PointColore pc , Point p); }


que faire de l'appel ?

Point p = new Point(); f(p,p);


ca compile pas, faut faire un cast

ici on peut pas faire de cast. Mais je me suis planté dans mon exemple :
c'est ca qui cause pb si on le fait en runtime

Point p = new PointColore();
PointColore pc = new PointColore();
f(p,pc);

Je pense qu'on pourrais p-e se démerder pour faire un algo qui pourrait chercher la signature la plus proche, mais ca risque d'etre vraiment lourd....

squalyl^2
:N'est il pas normal que le type de l'objet soit imposé par sa déclaration?

C'est du polymorphisme statique. Le polymorphisme dynamique veut dire que c'est le vrai type qui est pris en considération.

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

Même dans un environnement compilé, on peut (-> RTTI, cf. aussi le ./149 de Quesoft). Mais faire ça pour les méthodes surchargées détruit vite la performance, donc ce n'est pas fait automatiquement.

Quesoft
:Cependant, il reste une String, et si une méthode existe en deux versions, une qui peut traiter des String et une qui peut traiter des Objects, je trouverait plus normal que celle qui peut traiter des String soit appelée (car la nature de l'objet qui est passé en paramètre est une String).

Et c'est ce qui se passe en Java et Moka (sauf en Java pour les méthodes final, c'est-à-dire non-surchargeables). En C++, c'est ce qui se passe si la méthode est virtuelle, sinon, c'est du polymorphisme statique. Ça permet d'optimiser mieux (mais les méthodes non-virtuelles sont toujours un point d'emm*rde pour ceux qui veulent surcharger la classe).

hibOu :
si ca marche mais a condition que les structures soient organisée de la même manière.

Oui, malheureusement, une Interface vise à permettre à deux classe organisées complètement différemment d'implémenter une interface commune.

hibOu :
En fait, la question est : si on a une classe PointColoré qui hérite d'une classe Point, et si on a :

class truc {
  void f(Point p , PointColore pc);
  void f(PointColore pc , Point p);
}

que faire de l'appel ?

Point p = new Point();
f(p,p);

Je viens de tester avec java 1.4 : il refuse de compiler
Il ne veut pas compiler non plus :

Point p = new Point();
Point pc = new PointColore();
f(p,pc);

Je trouve normal, même avec le support d'un polymorphisme plus poussé, que dans un langage typé, f(p,p) soit refusé par le compilateur. Oui, un point, peut être un point coloré, mais pas nécessairement (alors que l'inverse est toujours vrai). Pour que le compilateur l'accepte, en Moka ou en Java, il faut caster la superclasse en la sous-classe dérivée : f(p,(PointColore)pc);

Si pc n'est pas une sous classe de PointColore, il y a une exception qui est soulevée en java. En Moka, watchout (comportement indéterminé), c'est dangereux.

hibOu :
Je pense qu'on pourrais p-e se démerder pour faire un algo qui pourrait chercher la signature la plus proche, mais ca risque d'etre vraiment lourd....

Moka utilise l'algo du 'premier du bord' (en bon québécois) : comme les deux méthodes sont aussi best match l'une que l'autre, il en prend une des deux, la première dans sa liste lors de la compilation.

Pour la lourdeur, quand la signature est générée à la compilation, tout ça se fait à la compilation, donc c'est pas dramatique.

Quesoft
:

hibOu :
si ca marche mais a condition que les structures soient organisée de la même manière.

Oui, malheureusement, une Interface vise à permettre à deux classe organisées complètement différemment d'implémenter une interface commune.

ceci n'est pas un problème :
MonInterface :
fct1, fct2, fct3

SubClasse1 implements MonInterface
fct1, fct2, fct3, fct_subclasse1

SubClasse2 implements MonInterface
fct1, fct2, fct3, fct_subclasse2

Le problème peut venir de l'inverse : un classe implémente plusieurs interfaces.
D'ailleurs, moka supporte-t-il plusieurs "implements", plusieurs "extends" ?

squalyl :
[...]

Ara ??

squalyl sans le ^2 ?

tu nous ressort ton vieux compte ?

hibOu
:

Quesoft
:

hibOu :
si ca marche mais a condition que les structures soient organisée de la même manière.

Oui, malheureusement, une Interface vise à permettre à deux classe organisées complètement différemment d'implémenter une interface commune.

ceci n'est pas un problème :
MonInterface :
fct1, fct2, fct3

SubClasse1 implements MonInterface
fct1, fct2, fct3, fct_subclasse1

SubClasse2 implements MonInterface
fct1, fct2, fct3, fct_subclasse2

Le problème peut venir de l'inverse : un classe implémente plusieurs interfaces.
D'ailleurs, moka supporte-t-il plusieurs "implements", plusieurs "extends" ?

Comme le Java, Moka supporte l’héritage simple, mais une classe peut implémenter plus d’une interface. Je vois mal comment on peut gérer ceci avec ton implantation des interfaces (voici une liste de quelques classes du package moka.x) :

Classe 1 :
public abstract class CaptionedComponent
extends Component
implements Captioned

Classe 2 :
public class Button
extends CaptionedComponent
implements Styled

Classe 3 :
public class Frame
extends Container
implements Captioned

Si je comprend bien, on devrait implémenter le tout :

Classe 1
fct_captioned, fct_component, fct_subclasse1

Classe 2
fct_styled, fct_captioned, fct_component, fct_subclasse2

Classe 3
fct_captioned, fct_container, fct_subclasse2

Alors, le code suivant ne fonctionnera pas :

Captionned c = new Button();

c.fct_captioned(); //Car comme membre de la fct_captioned struct Captioned, on a un pointeur vers fct_styled

Si tu décides de faire :

Classe 2
fct_styled, fct_captioned, fct_component, fct_subclasse2

Alors, le code suivant ne fonctionnera pas :

Styled s = new Button();

s.fct_styled(); //Car comme membre de la fct_styled struct Styled, on a un pointeur vers fct_captioned

Un de ces quatres si je me remet au smalltalk je pourrait ptet porter une vm allégé sur ti

Quesoft> Ben il suffit de mettre les fonctions héritées et définies dans la classe au début de la structure, puis de mettre les tables de fonctions virtuelles correspondant aux interfaces voulues seulement après ; comme ça, si tu castes la classe vers une classe parent, le pointeur reste le même (comme ça doit être implémenté dans Moka), mais si tu castes la classe vers une interface, il suffit de décaler le pointeur (et faire en sorte que les fonctions membres tiennent compte de ce décalage, évidemment)

Quesoft
:

hibOu
:

Quesoft
:

hibOu :
si ca marche mais a condition que les structures soient organisée de la même manière.

Oui, malheureusement, une Interface vise à permettre à deux classe organisées complètement différemment d'implémenter une interface commune.

ceci n'est pas un problème :
MonInterface :
fct1, fct2, fct3

SubClasse1 implements MonInterface
fct1, fct2, fct3, fct_subclasse1

SubClasse2 implements MonInterface
fct1, fct2, fct3, fct_subclasse2

Le problème peut venir de l'inverse : un classe implémente plusieurs interfaces.
D'ailleurs, moka supporte-t-il plusieurs "implements", plusieurs "extends" ?

Comme le Java, Moka supporte l’héritage simple, mais une classe peut implémenter plus d’une interface. Je vois mal comment on peut gérer ceci avec ton implantation des interfaces (voici une liste de quelques classes du package moka.x) :

Classe 1 :
public abstract class CaptionedComponent
extends Component
implements Captioned

Classe 2 :
public class Button
extends CaptionedComponent
implements Styled

Classe 3 :
public class Frame
extends Container
implements Captioned

Si je comprend bien, on devrait implémenter le tout :

Classe 1
fct_captioned, fct_component, fct_subclasse1

Classe 2
fct_styled, fct_captioned, fct_component, fct_subclasse2

Classe 3
fct_captioned, fct_container, fct_subclasse2

Alors, le code suivant ne fonctionnera pas :

Captionned c = new Button();

c.fct_captioned(); //Car comme membre de la fct_captioned struct Captioned, on a un pointeur vers fct_styled

Si tu décides de faire :

Classe 2
fct_component, fct_subclasse2, fct_styled, fct_captioned

Alors, le code suivant ne fonctionnera pas :

Styled s = new Button();

s.fct_styled(); //Car comme membre de la fct_styled struct Styled, on a un pointeur vers fct_captioned

effectivement, la solution que je propose ne marche que pour un seul héritage.
Faut l'adapter comme le dit Pollux:

Pollux :
Quesoft> Ben il suffit de mettre les fonctions héritées et définies dans la classe au début de la structure, puis de mettre les tables de fonctions virtuelles correspondant aux interfaces voulues seulement après ; comme ça, si tu castes la classe vers une classe parent, le pointeur reste le même (comme ça doit être implémenté dans Moka), mais si tu castes la classe vers une interface, il suffit de décaler le pointeur (et faire en sorte que les fonctions membres tiennent compte de ce décalage, évidemment)

ca peut donner un truc du genre :
cl1 implements it1
fct_cl1...
fct_it1...

cl2 implements it2 extends cl1
fct_cl1...
fct_cl2...
fct_it2...

cl3 implements it1,it2 extends Object
fct_object...
fct_cl3...
fct_it1...
fct_it2...

Il reste la gestion des décalages des tables de fionctions des implémentation des interfaces...
p-e un tableau des décalage de toutes les interfaces associé à chaque classe ?
cl1 :
decal_it1 (=nb_fct_cl1)
decal_it2 (=0 : ne doit jamais etre appelé)
cl2 :
decal_it1 (=0 : ne doit jamais etre appelé)
decal_it2 (=nb_fct_cl1+nb_fct_cl2)
cl3 :
decal_it1 (=nb_fct_object+nb_fct_cl3)
decal_it2 (=nb_fct_object+nb_fct_cl3+nb_fct_it1)

Godzil :
Un de ces quatres si je me remet au smalltalk je pourrait ptet porter une vm allégé sur ti

Ce sera un projet intéressant. Je ne connais pas beaucoup smalltalk cependant (j'ai lu un peu sur le sujet seulement).

Pollux :
Quesoft> Ben il suffit de mettre les fonctions héritées et définies dans la classe au début de la structure, puis de mettre les tables de fonctions virtuelles correspondant aux interfaces voulues seulement après ; comme ça, si tu castes la classe vers une classe parent, le pointeur reste le même (comme ça doit être implémenté dans Moka), mais si tu castes la classe vers une interface, il suffit de décaler le pointeur (et faire en sorte que les fonctions membres tiennent compte de ce décalage, évidemment)

Et si je cast une interface vers une autre ?

Captioned o;
Styled s;

s = o; //De combien décaler ? o peut être nimporte quoi.

Solution Moka :
Si Captioned a une méthode setCaption, Moka définit un vecteur de pointeur vers des méthodes. Le vecteur a une taille de n qui correspond au nombre de classes. Lorsque j’invoque setCaption d’un Captioned, Moka traduit :

Captioned c = new Button();
c.setCaption(‘’Hello’’);

par :

Captioned_setCaption_String_ProtArray[c->class_id](c, TString_char_p(‘’Hello’’)) ;

Donc, un peut plus lent qu’une invocation normale, mais assez rapide tout de même …

En fait, dans l’implémentation actuelle, une méthode intermédiaire est appelée, mais c’est inutile (trace d’un vieux design), dans la prochaine version, le call sera traduit comme plus haut.

Quesoft
: Et si je cast une interface vers une autre ?

Hmmf en fait t'as raison ma méthode ne marche que si t'as pas d'upcast (i.e. comme en caml [suuxxx!!!])

Pollux
:

Quesoft
: Et si je cast une interface vers une autre ?

Hmmf en fait t'as raison ma méthode ne marche que si t'as pas d'upcast (i.e. comme en caml [suuxxx!!!])

Je ne connais pas caml, mais je vois ce que tu veux dire...

Quesoft :
Solution Moka :
Si Captioned a une méthode setCaption, Moka définit un vecteur de pointeur vers des méthodes. Le vecteur a une taille de n qui correspond au nombre de classes. Lorsque j’invoque setCaption d’un Captioned, Moka traduit :

Captioned c = new Button();
c.setCaption(‘’Hello’’);

par :
Captioned_setCaption_String_ProtArray[c->class_id](c, TString_char_p(‘’Hello’’)) ;

moi je pensais à un truc du genre :
c->tab_fonctions[ c->tab_decal_int[id_Captioned] + id_fonctions ]
ta solution est meilleure.

Quesoft
:

Pollux
:

Quesoft
: Et si je cast une interface vers une autre ?

Hmmf en fait t'as raison ma méthode ne marche que si t'as pas d'upcast (i.e. comme en caml [suuxxx!!!])

Je ne connais pas caml, mais je vois ce que tu veux dire...

on peut m'expliquer ?

Object s = "hello";
String l = ((String)s).lowercase();

En gros ça veut dire que même si qqch est un Object, si à la base c'était une String tu peux en faire un String (et sinon tu te chopes une exception).

C'est moyennement propre, mais c'est indispensable en l'absence de types génériques ()

Godzil
:

squalyl :
[...]

Ara ??

squalyl sans le ^2 ?

tu nous ressort ton vieux compte ?

gomen!

j'ai posté depuis un autre ordi en utilisant le formulaire du bas, je suis allé trop vite et comme y'a le même pass, ca a marché. C'est bien moi qui ai posté

J'ai encore fait quelques tests de moka et y'a un bug :
Si je lance moka par :

C:\.....\moka\mdk2.2>Moka.exe ..\Examples\Hello\Hello.java

pas de pb
Si je lance moka par :

C:\.....\moka>mdk2.2\Moka.exe Examples\Hello\Hello.java

plantage de Moka. En fait, apparement, il faut être dans le répertoire de Moka pour que cela fonctionne correctement...

tion des packages à l'air d'être assez spéciale. J'ai un fichier hello.java qui est dans le paquetage pack : je déclare donc package pack;Aussi, la geset je met ce fichier dans un dossier pack. Apparement, moka veut que je mette tout ca dans tigcc\package\... c'est normal ? Je ne peux pas faire de paquetage dans le dossier de mon "projet" ?

PS:j'ai pas trouvé de topic sur moka dans le forum Ti, donc je le post ici...

hibOu :
J'ai encore fait quelques tests de moka et y'a un bug :
Si je lance moka par :

C:\.....\moka\mdk2.2>Moka.exe ..\Examples\Hello\Hello.java

pas de pb
Si je lance moka par :

C:\.....\moka>mdk2.2\Moka.exe Examples\Hello\Hello.java

plantage de Moka. En fait, apparement, il faut être dans le répertoire de Moka pour que cela fonctionne correctement...

Malheureusement oui. Le problème vient du fait que lorsque Moka est exécuté ailleurs que dans son répertoire, il cherche ses fichiers dans le répertoire courrant. J'admet que de un, je devrais setter une variable d'environnement pour permettre à Moka d'être invoqué n'importe où et de deux, je devrais émettre des messages d'erreur significatifs.

hibOu :
tion des packages à l'air d'être assez spéciale. J'ai un fichier hello.java qui est dans le paquetage pack : je déclare donc package pack;Aussi, la geset je met ce fichier dans un dossier pack. Apparement, moka veut que je mette tout ca dans tigcc\package\... c'est normal ? Je ne peux pas faire de paquetage dans le dossier de mon "projet" ?

PS:j'ai pas trouvé de topic sur moka dans le forum Ti, donc je le post ici...

Oui, c'est très limitatif comme système (et ça peut être corrigé), je le reconnais ...

Moka, bien qu'assez fonctionnel pour permettre le développement d'applications variées, n'a pas atteint la même maturité que d'autres environnements de développement.

En ce sens, il serait intéressant de développer le projet en communauté, des gens pourrait poster des améliorations aux classes existantes, des nouvelles classes, alternatives ou même très spécifiques (je suis pas contre de distribuer des packages com.votreCompagnie dans mes releases), on pourrait continuer de discuter des détails d'implémentations (comme on l'a fait pour l'invocation des méthodes), etc.

Je suis sûr que l'on peut dépasser le stade de 'potabilité', i.e. faire un précompilateur très efficasse ... optimal si possible.

Il y a des gadget le fun avec Moka, c'est vraiment adapté pour l'optimisation. Par exemple, l'appel une méthode statique déclarée comme abstraite peut être remplacée par l'appel d'une macro. Application pratique :

System.print(34345);

est converti :

printf("%d", 34345); //Peut être qu'il y a une manière plus efficiente (rapidité et taille) pour faire la même chose, hésitez pas à en parler ...

Quesoft
:

hibOu :
tion des packages à l'air d'être assez spéciale. J'ai un fichier hello.java qui est dans le paquetage pack : je déclare donc package pack;Aussi, la geset je met ce fichier dans un dossier pack. Apparement, moka veut que je mette tout ca dans tigcc\package\... c'est normal ? Je ne peux pas faire de paquetage dans le dossier de mon "projet" ?

PS:j'ai pas trouvé de topic sur moka dans le forum Ti, donc je le post ici...

Oui, c'est très limitatif comme système (et ça peut être corrigé), je le reconnais ...

Pour les packages, il faudrait juste changer l'algo de recherche du package :
- d'abord rechercher dans le répertoire de la source que l'on compile
- ensuite rechercher dans les packages de moka.

Moka, bien qu'assez fonctionnel pour permettre le développement d'applications variées, n'a pas atteint la même maturité que d'autres environnements de développement.

En ce sens, il serait intéressant de développer le projet en communauté, des gens pourrait poster des améliorations aux classes existantes, des nouvelles classes, alternatives ou même très spécifiques (je suis pas contre de distribuer des packages com.votreCompagnie dans mes releases), on pourrait continuer de discuter des détails d'implémentations (comme on l'a fait pour l'invocation des méthodes), etc.

Je suis sûr que l'on peut dépasser le stade de 'potabilité', i.e. faire un précompilateur très efficasse ... optimal si possible.

Il y a des gadget le fun avec Moka, c'est vraiment adapté pour l'optimisation. Par exemple, l'appel une méthode statique déclarée comme abstraite peut être remplacée par l'appel d'une macro. Application pratique :

System.print(34345);

est converti :

printf("%d", 34345); //Peut être qu'il y a une manière plus efficiente (rapidité et taille) pour faire la même chose, hésitez pas à en parler ...

Je ne pense pas qu'il faille changer l'implémentation de cette fonction. Par contre, comme tu le souligne, il devra être possible d'ajouter des nouveaux paquetages qui implémente de facon différente les fonctions graphiques par exemple. Par exemple, ajouter un paquetage com.extgraph.xxx

hibOu :
Pour les packages, il faudrait juste changer l'algo de recherche du package :
- d'abord rechercher dans le répertoire de la source que l'on compile
- ensuite rechercher dans les packages de moka.

En effet, c'est ce qui me paraît le plus logique ...

Pour les objets avec un scope, quelle syntaxe je devrais adopter ?

J’avais pensé à quelque chose du genre :

<mot clé style, par exemple ‘auto’ > <Type> nomDeLaVariable(<arguments du constructeur>) ;

Exemple :

auto Vector v(10, 5) ;

Mais quel différent type de scope (=portée si j'ai bien pigé) tu définirais ?

hibOu :
Mais quel différent type de scope (=portée si j'ai bien pigé) tu définirais ?

Très simple : semblable aux variable locales ...

Ex :

{
  auto Vector v(5,10);
}

serait traduit :

{
  TVector mem_for_v; //Nom fictif
  TVector *v = &mem_for_v; 
  TVector0(v);
  Vector__short_int_short_int(v, 5, 10);
}

Je vois ce que tu veux faire. Mais moi je n'aime pas trop jouer avec la mémoire avec trop de précision, ca mène trop souvent vers des "segmentation fault". C'est pour ca que j'aime bien Java.
Dans ton exemple, si on fait
return v;
......... :/

En même temps, on est sur Ti....

Et pourquoi pas des :

Vector v = newlocal Vector(10,5);
Vector v2 = newglobal Vector(10,5);

pour rester plus proche de la syntaxe java ?

hibOu :
Je vois ce que tu veux faire. Mais moi je n'aime pas trop jouer avec la mémoire avec trop de précision, ca mène trop souvent vers des "segmentation fault". C'est pour ca que j'aime bien Java.
Dans ton exemple, si on fait
return v;
......... :/

En même temps, on est sur Ti....

Et pourquoi pas des :

Vector v = newlocal Vector(10,5);
Vector v2 = newglobal Vector(10,5);

pour rester plus proche de la syntaxe java ?

Pas fou comme idée ... Je pense que ce serait une solution acceptable ...

Le problème c'est qu'il faut que le programmeur soit conscient que [code]newlocal Vector(10,5);[/code] ne retourne pas une nouvelle instance, mais retourne plutôt une référence vers un objet global ou local, on ne pourrais pas taper :
[code]for (short i = 0; i < nb;i++) {
v.add(newglobal Object());
}
[/code]

C'est ce que j'ai utilisé comme tactique pour les matrices et les vecteurs en Power Basic btw ...

Quesoft
:

hibOu :
Je vois ce que tu veux faire. Mais moi je n'aime pas trop jouer avec la mémoire avec trop de précision, ca mène trop souvent vers des "segmentation fault". C'est pour ca que j'aime bien Java.
Dans ton exemple, si on fait
return v;
......... :/

En même temps, on est sur Ti....

Et pourquoi pas des :

Vector v = newlocal Vector(10,5);
Vector v2 = newglobal Vector(10,5);

pour rester plus proche de la syntaxe java ?

Pas fou comme idée ... Je pense que ce serait une solution acceptable ...

Le problème c'est qu'il faut que le programmeur soit conscient que [code]newlocal Vector(10,5);[/code] ne retourne pas une nouvelle instance, mais retourne plutôt une référence vers un objet global ou local, on ne pourrais pas taper :
[code]for (short i = 0; i < nb;i++) {
v.add(newglobal Object());
}
[/code]

C'est ce que j'ai utilisé comme tactique pour les matrices et les vecteurs en Power Basic btw ...

Il en est de même pour :
[code]for (short i = 0; i < nb;i++) {
auto Object o(5,10);
v.add(o);
}
[/code]
C'est pour ca que je n'aime pas trop ce genre d'ajout..... mais bon...

hibOu :
Il en est de même pour :
for (short i = 0; i < nb;i++) {
auto Object o(5,10);
v.add(o);
}

Effectivement, je voulais seulement dire que

auto Object o(5,10);

ressemble plus à :

Object o;

hibOu :
C'est pour ca que je n'aime pas trop ce genre d'ajout..... mais bon...

Moi non plus, mais ça semble répondre à certains besoins ...

J'ai pris en compte vos observations et j'ai un béta de la prochaine release de Moka :

Distribution complète :
http://quesoft.dyndns.org:8080/dev/moka/beta/mokabeta.zip

MDK uniquement :
http://quesoft.dyndns.org:8080/dev/moka/beta/mdkbeta.zip

Les nouveautés sont, en gros :

- Objets locaux et globaux, voici un exemple de programme :

http://quesoft.dyndns.org:8080/dev/moka/beta/Scoped.java

- La classe VatEntry (qui permet un accès direct aux fichiers en RAM), voici un exemple d'utilisation :

http://quesoft.dyndns.org:8080/dev/moka/beta/VatDemo.java

<edit>

J'oubliais, le TextArea a maintenant un scrollbar, voici un screenshot :

http://quesoft.dyndns.org:8080/dev/moka/beta/screen89.gif

<edit>

... et il y a un exécutable pour Linux d'inclu, la syntaxe est la même :

./Moka <classe principale>

au lieu de

Moka <classe principale>

nb : Le source est identique pour la version Linux et Windows.