Comment coder un enum via une classe « normale »

Wykaaa a écrit :

Tu veux dire qu'il y aura un mécanisme de décision (if ou switch) à la
suite du tirage aléatoire pour savoir s'il faut créer telle ou telle
pièce ?
La réponse est oui, car les switch qui restent sont ceux qui dépendent
de mécanismes non typés. Par exemple, dans une analyse lexicale, ce qui
est lu est le fichier d'entrée (donc des caractères). Là on est bien
obligé d'avoir des if pour savoir si on a lu un opérateur, un blanc, un
chiffre, etc... car ce qu'on lit est non typé.

Ok. J'avais un petit doute et je me demandais si le polymorphisme ne
pouvais pas éradiquer *tous* les switch. Mais effectivement, tout ce qui
ne relève pas du type n'est pas du ressort du polymorphisme.

Merci beaucoup.


--
François Lafont

Francois a écrit :

Mais au final, dans mon Tetris, dès fois je vais tomber sur un carré et
dès fois sur un demi-T de mamière aléatoire. Donc, au final, forcémentx
quelque part dans le code j'aurais au moins une fois un swith (ou des
if), non ?

En fait oui, pour la simple et bonne raison qu'un processeur standard
n'a fondamentalement pas de notion de d'heritage et de polymorphisme, et
que la seule chose qu'il sache faire ce sont du calcul arithméthique, et
des gotos +/- conditionnels.

Donc quoi qu'on fasse, au final le processeur il s'en tape du
polymorphisme qui est un truc qui n'a de sens que dans les couches soft
bien au dessus de lui (même l'OS s'en fiche de ce truc là).

sam.

Wykaaa a écrit :

La réponse est oui, car les switch qui restent sont ceux qui dépendent
de mécanismes non typés. Par exemple, dans une analyse lexicale, ce qui
est lu est le fichier d'entrée (donc des caractères). Là on est bien
obligé d'avoir des if pour savoir si on a lu un opérateur, un blanc, un
chiffre, etc... car ce qu'on lit est non typé.

Je ne suis pas 100% d'accord. Pourquoi on aurait pas une classe pour les
opérateurs, une classe pour les blancs, une classe pour les chiffres, le
tout héritant d'une classe décrivant les caractères ? Rien ne l'interdit
en théorie.

Tiens, je reprends le cas du smalltalk que je connais et qui pousse
l'objet assez loin. Dans ce langage là il n'y a pas vraiment de
booleens. Il y a une class, disons Logic, avec deux sous classe True et
False ne contenant qu'une seule instance chacune.

C'est assez mmusant, car comme il y a de la Block-Closure, les if/then
les operations booleenes s'ecrivent uniquement via le polymorphisme. On
a plus aucun if ou switch dans un code. On peut s'en approcher en java
(pas 100% identique à cause du typage fort, mais ici seul le principe
compte pour la demonstration) en remplacant les Block-Closure par des
Runnable(). Ca donnerait ceci:

// un objet qui connait les Logic
interface MyObject {
Logic eq(MyObject other);
}

// block de code
interface Runnable {
void run();
}

interface Logic extends MyObject {
Logic and(Logic other);
Logic or(Logic other);
Logic not();
Logic ifTrue(Runable code);
Logic ifFalse(Runable code);
}

public True implements Logic {
public final True TRUE = new True();
private True(){};
public Logic or(Logic other) {return this;}
public Logic and(Logic other) {return other;}
public Logic not() {return False.FALSE;}
public void ifTrue(Runnable code) {code.run(); return this;}
public void ifFalse(Runnable code) {return this;}

public Logic eq(Logic other) {return other;}
}

public False implements Logic {
public final True FALSE = new False();
private False() {};
public Logic or(Logic other) {return other;}
public Logic and(Logic other) {return this;}
public Logic not() {return False.TRUE;}
public void ifTrue(Runnable code) {return this;}
public void ifFalse(Runnable code) {code.run(); return this;}

public Logic eq(Logic other) {return other.not();}
}


Avec ceci, if(a==b) {...code1...} else {...code2...} devient:
a.eq(b)
.ifTrue(new Runnable() {public void run(){...code1...}})
.ifFalse(new Runnable() {public void run(){...code2...}});

Pas un seul if(), tout se fait par le dispatching !!

sam.

Samuel Devulder a écrit :

public False implements Logic {
public final True FALSE = new False();

OOps Lire:
public final False FALSE = new False();
(j'aurais mieux fait d'appeller ces trucs là INSTANCE: True.INSTANCE et
False.INSTANCE).


sam.

Samuel Devulder a écrit :

En fait oui, pour la simple et bonne raison qu'un processeur standard
n'a fondamentalement pas de notion de d'heritage et de polymorphisme, et
que la seule chose qu'il sache faire ce sont du calcul arithméthique, et
des gotos +/- conditionnels.

Donc quoi qu'on fasse, au final le processeur il s'en tape du
polymorphisme qui est un truc qui n'a de sens que dans les couches soft
bien au dessus de lui (même l'OS s'en fiche de ce truc là).

Ok, c'est très clair.

Merci à vous deux, Samuel et Wykaaa, pour vos explications très
enrichissantes.

À+


--
François Lafont

Samuel Devulder <samuel-dot-devulder@geensys.com> writes:

Mais au final, dans mon Tetris, dès fois je vais tomber sur un carré
et dès fois sur un demi-T de mamière aléatoire. Donc, au final,
forcémentx quelque part dans le code j'aurais au moins une fois un
swith (ou des if), non ?

En fait oui,

Non.

pour la simple et bonne raison qu'un processeur standard
n'a fondamentalement pas de notion de d'heritage et de polymorphisme,
et que la seule chose qu'il sache faire ce sont du calcul
arithméthique, et des gotos +/- conditionnels.

Et des branchements indirects. L'équivalent d'appeler une fonction en
C via un pointeur, d'une certaine façon. C'est comme cela que la
liaison dynamique est faite.

-- Alain.

Samuel Devulder a écrit :

Wykaaa a écrit :

La réponse est oui, car les switch qui restent sont ceux qui dépendent
de mécanismes non typés. Par exemple, dans une analyse lexicale, ce
qui est lu est le fichier d'entrée (donc des caractères). Là on est
bien obligé d'avoir des if pour savoir si on a lu un opérateur, un
blanc, un chiffre, etc... car ce qu'on lit est non typé.

Je ne suis pas 100% d'accord. Pourquoi on aurait pas une classe pour les
opérateurs, une classe pour les blancs, une classe pour les chiffres, le
tout héritant d'une classe décrivant les caractères ? Rien ne l'interdit
en théorie.

Oui, en théorie...
Je suis d'accord qu'on peut pousser le bouchon le plus loin possible
mais ça devient compliqué dans des langages qui ne sont pas 100% objet
tels que C++ ou Java.

Tiens, je reprends le cas du smalltalk que je connais et qui pousse
l'objet assez loin. Dans ce langage là il n'y a pas vraiment de
booleens. Il y a une class, disons Logic, avec deux sous classe True et
False ne contenant qu'une seule instance chacune.

Oui mais Smalltalk est un langage clos par rapport à l'objet (tout est
objet, y compris les classes, c'est pour cela qu'on y parle de
métaclasse). Alors là, c'est effectivement plus facile qu'en C++ et en
Java d'éliminer toutes les alternatives et les switch.

C'est assez mmusant, car comme il y a de la Block-Closure, les if/then
les operations booleenes s'ecrivent uniquement via le polymorphisme. On
a plus aucun if ou switch dans un code. On peut s'en approcher en java
(pas 100% identique à cause du typage fort, mais ici seul le principe
compte pour la demonstration) en remplacant les Block-Closure par des
Runnable(). Ca donnerait ceci:

// un objet qui connait les Logic
interface MyObject {
Logic eq(MyObject other);
}

// block de code
interface Runnable {
void run();
}

Je suis d'accord, il faut que chaque objet soit actif (contienne son
propre "thread" ou processus. Mais avoue que ça complique quand même les
choses. Cependant j'adore cette façon de programmer en Java mais elle
n'est pas habituelle. Ca doit être pour cette raison que dans d'autres
fils assez anciens (plusieurs années), je me suis pris des baffes ;-)

interface Logic extends MyObject {
Logic and(Logic other);
Logic or(Logic other);
Logic not();
Logic ifTrue(Runable code);
Logic ifFalse(Runable code);
}

public True implements Logic {
public final True TRUE = new True();
private True(){};
public Logic or(Logic other) {return this;}
public Logic and(Logic other) {return other;}
public Logic not() {return False.FALSE;}
public void ifTrue(Runnable code) {code.run(); return this;}
public void ifFalse(Runnable code) {return this;}

public Logic eq(Logic other) {return other;}
}

public False implements Logic {
public final True FALSE = new False();
private False() {};
public Logic or(Logic other) {return other;}
public Logic and(Logic other) {return this;}
public Logic not() {return False.TRUE;}
public void ifTrue(Runnable code) {return this;}
public void ifFalse(Runnable code) {code.run(); return this;}

public Logic eq(Logic other) {return other.not();}
}


Avec ceci, if(a==b) {...code1...} else {...code2...} devient:
a.eq(b)
.ifTrue(new Runnable() {public void run(){...code1...}})
.ifFalse(new Runnable() {public void run(){...code2...}});

Pas un seul if(), tout se fait par le dispatching !!

sam.

J'a... doooooore !
Mais je ne voulais pas effrayer François ;-)

Samuel Devulder a écrit :

Samuel Devulder a écrit :

public False implements Logic {
public final True FALSE = new False();

OOps Lire:
public final False FALSE = new False();
(j'aurais mieux fait d'appeller ces trucs là INSTANCE: True.INSTANCE et
False.INSTANCE).


sam.

On avait rectifié de nous-mêmes...

Alain Ketterlin a écrit :

Mais au final, dans mon Tetris, dès fois je vais tomber sur un carré
et dès fois sur un demi-T de mamière aléatoire. Donc, au final,
forcémentx quelque part dans le code j'aurais au moins une fois un
swith (ou des if), non ?

En fait oui,

Non.

Ah, serait-ce possible d'avoir un bout de code java (même un peu
elliptique par endroit), où l'on crée dès fois une pièce de type Carre,
dès fois de type demi-T, sans utiliser le moindre switch ou if
équivalent ? Car là, je ne vois pas du tout comment c'est possible.


--
François Lafont

Wykaaa a écrit :.

J'a... doooooore !
Mais je ne voulais pas effrayer François ;-)

C'est gentil d'avoir pensé à moi. :-)

Je garde ce code dans un coin pour essayer de le potasser, car là comme
ça c'est trop dur.


--
François Lafont