Discussion :

[e-ric]

Je trouve aussi ce projet très intéressant à plusieurs titres.

Peux-tu développer ?

Le jeu est généré aléatoirement, la solution est donc connue dès le départ, il suffit de conserver les ampoules obtenues lors du tirage aléatoire.

Dans ce genre de jeu, il n'est pas besoin de chercher des complications.

Cdlt

[Roland Chastain]

Peux-tu développer ?

Je veux dire que le projet est intéressant à la fois comme exemple d'interface graphique, comme exemple d'utilisation des génériques (Gilles dixit, moi je ne sais pas trop ce que c'est, mais justement c'est l'occasion d'apprendre) et pour le jeu lui-même.

[gvasseur58]

Une question au passage : est-il indiscret de te demander pourquoi tu es resté à la version 1.2.6 (avec FPC 2.6.4) ?

Je suis comme Roland, intéressé par une application qui fait usage de techniques peu usitées bien que très pratiques : pour ma part, je pense surtout aux énumérateurs.

Cordialement,

Gilles

[e-ric]

Je crois que j'ai gagné !

Bon ben maintenant, essaie avec un côté de 15 ampoules !

Une question au passage : est-il indiscret de te demander pourquoi tu es resté à la version 1.2.6 (avec FPC 2.6.4) ?

Je suis comme Roland, intéressé par une application qui fait usage de techniques peu usitées bien que très pratiques : pour ma part, je pense surtout aux énumérateurs.

Je l'ai développé et compilé avec Lazarus 1.6+FPC 3.0, qu'est ce qui te laisse penser que je l'ai fait avec une ancienne version ?

J'ai employé un énumérateur pour accéder aux voisines d'une ampoule car j'avais en vue d'implémenter plus tard des voisinages plus complexes, l'unification d'accès par un itérateur qui masque le détails des accès était donc pertinente. Mais dans le programme actuel, c'est plutôt un luxe ; cela simplifie une partie du code mais n'est pas indispensable.

Les énumérateurs c'est sympa mais ils peuvent être délicats à écrire, car il faut isoler le code de l'itération dans une classe, ce qui n'est pas toujours évident. Je préférerais pouvoir définir des générateurs (comme dans Python), ils sont plus simples à mettre en œuvre, une simple itération dans une procédure suffit souvent, pas besoin de créer une classe pour cela.

Je veux dire que le projet est intéressant à la fois comme exemple d'interface graphique, comme exemple d'utilisation des génériques (Gilles dixit, moi je ne sais pas trop ce que c'est, mais justement c'est l'occasion d'apprendre) et pour le jeu lui-même.

J'ai voulu une interface un peu originale offrant une certaine cohérence mais n'étant pas graphiste, je me suis limité à des choix simples.

La généricité est la possibilité de paramétrer des types, ainsi une classe pourra être conçue de manière incomplète en spécifiant des types formels et inconnus dans le corps de la classe générique.
L'emploi du type générique est la spécialisation (terminologie FPC) qui consiste à spécifier les paramètres types effectifs.
Classiquement, les types génériques sont employés pour définir des types conteneurs comme des listes par exemple. L'avantage est que l'on écrit une unique fois le code de la classe, celle-ci devient un patron (au sens de la couture) pour une inifinité de classes. C'est le compilateur qui se charge de dupliquer le code issu de la spécialisation.

Pour illustrer cela, mon programme met en oeuvre la classe suivante :

Code :

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

TFPGObjectList<T> = class(TFPSList)

C'est une liste d'objets dont le type (unique) est inconnu dans le source de la classe mais qui est référencé par un nom, ici T. Je voulais une liste d'ampoules donc, plutôt que créer un nouveau type, tout coder et gagner peut-être de bons moments de débogage, j'ai préféré exploiter le type générique en le spécialisant :

Code :

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

TBulbList = specialize TFPGObjectList<TBulb>;

conclusion : une ligne de code et je profite du typage statique, c'est tout bénef.

Attention:
- coder un type générique demande un soin particulier pour rendre ensuite parfaitement service.
- les différences entre les classes et les autres types peuvent introduire des difficultés supplémentaires, qui sont un peu atténuées avec l'ajout récent de la fonction (intrinsèque) Default dans la version 3.0 que j'attendais avec impatience.
- les syntaxes supportant la généricité de Delphi et de FPC sont différentes, ce qui amène une rupture supplémentaire entre les deux langages. C'est tant mieux pour FPC qui trace ainsi sa propre route et n'est plus une pâle copie de D7.

Je pense que ceux qui veulent écrire du code compilable dans les 2 langages auront un travail de plus en plus compliqué, la question sera de savoir si cela en vaut la peine.

J'espère avoir éclairci quelques points. Merci de l'intérêt que vous portez à ce sujet.

Cdlt

[gvasseur58]

Je l'ai développé et compilé avec Lazarus 1.6+FPC 3.0, qu'est ce qui te laisse penser que je l'ai fait avec une ancienne version ?

J'avais deux indices :

• le premier, très subjectif, est ta signature
• le second est le fichier .lps qui trahit ton travail : (extrait)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<Unit8>
        <Filename Value="/usr/share/lazarus/1.2.0/lcl/interfaces/gtk2/gtk2widgetset.inc"/>
        <TopLine Value="2818"/>
        <CursorPos X="22" Y="2828"/>
        <UsageCount Value="3"/>
      </Unit8>
      <Unit9>
        <Filename Value="/usr/share/lazarus/1.2.0/lcl/lclintf.pas"/>
        <UnitName Value="LCLIntf"/>
        <UsageCount Value="3"/>
      </Unit9>
      <Unit10>
        <Filename Value="/usr/share/fpcsrc/2.6.4/rtl/inc/systemh.inc"/>
        <TopLine Value="648"/>
        <CursorPos X="64" Y="596"/>
        <UsageCount Value="10"/>
      </Unit10>
      <Unit11>
        <Filename Value="/usr/share/fpcsrc/2.6.4/rtl/linux/system.pp"/>
        <UnitName Value="System"/>
        <TopLine Value="119"/>
        <CursorPos X="6" Y="140"/>
        <UsageCount Value="3"/>
      </Unit11>
      <Unit12>
        <Filename Value="/usr/share/fpcsrc/2.6.4/rtl/inc/system.inc"/>
        <TopLine Value="547"/>
        <CursorPos X="43" Y="576"/>
        <UsageCount Value="3"/>
      </Unit12>
      <Unit13>
        <Filename Value="/usr/share/lazarus/1.2.2/lcl/grids.pas"/>
        <UnitName Value="Grids"/>
        <CursorPos Y="14"/>
        <UsageCount Value="3"/>
      </Unit13>
      <Unit14>
        <Filename Value="/usr/share/lazarus/1.2.2/lcl/graphics.pp"/>
        <UnitName Value="Graphics"/>
        <TopLine Value="411"/>
        <CursorPos X="14" Y="425"/>
        <UsageCount Value="6"/>
      </Unit14>
      <Unit15>
        <Filename Value="/usr/share/fpcsrc/2.6.4/rtl/objpas/fgl.pp"/>
        <TopLine Value="263"/>
        <CursorPos X="10" Y="272"/>
        <UsageCount Value="21"/>
      </Unit15>

Étrange, non ? Mais ce n'était que simple curiosité...

Cordialement,

Gilles

[e-ric]

et pourtant seuls Laz1.6 est installé sur ma Debian. Mais il est vrai que j'ai commencé le projet avec une ancienne version de Laz.

Ah oui, effectivement, je n'ai pas mis à jour ma signature, je vais le faire.

@+