Discussion :

[SpiceGuid]

La question vaut aussi bien pour mon usage personnel que pour un cours/tutoriel.
C'est pour ça que je poste ici plutôt que dans le forum d'entraide GTK+, à cause des implications au niveau rédactionnel.

J'ai d'abord commencé à jouer avec l'interface POO parce que c'est celle qui est d'abord présentée, à la fois dans la doc officielle et dans le wiki cocan.

Mais maintenant je m'aperçois que:

• je ne peux pas faire certaines choses avec l'interface POO (par exemple modifier le titre d'une fenêtre), je n'ai pas encore vérifié mais il semblerait que ce soit possible avec l'interface procédurale.
• pourquoi faire simple si on peut faire compliqué, je ne vois rien que l'interface POO puisse faire et pas l'interface de bas niveau
• le tutoriel pour C du forum GTK est très bon, le transfert de la documentation et de l'expérience sont d'autant plus facile que l'interface est plus proche.
• enfin, à titre personnel, je ne vois pas pourquoi je devrais présenter la POO en OCaml rien que pour LablGtk (entendons nous bien, la POO en OCaml est sans doute très intéressante, mais il y a plein de choses intéressantes et la POO n'est une priorité pour moi).
  la présentation de LablGtk serait considérablement simplifiée si elle ne reposait que sur les chapitres que j'ai déjà rédigés (les styles fonctionnel et procédural).
  je ne maîtrise pas du tout la POO en OCaml et dans l'immédiat je n'ai pas de raison de m'y mettre sérieusement.

Autre critère, j'aimerais, autant que possible faciliter la transition entre LablGtk et GTK# (dans les deux sens bien entendu).
Liens GTK# :
http://www.mono-project.com/GtkSharp
http://vincentlaine.developpez.com/t...tnet/gtksharp/

Les extraits de code GTK# que j'ai pu voir jusqu'à présent restent quand même assez proches du style procédural, à mon avis c'est le style qui s'impose de facto. Même si le style LablGtk2 est bien plus simple et plus concis et sans doute amplement suffisant pour débuter, pour moi la principale motivation à programmer pour GTK c'est justement de ne pas s'enfermer dans une API de niche.

Bref, j'attends vos commentaires, et si personne ne défend vaillamment le stype OO en LablGtk alors je vais me rabattre sur le style procédural, à l'aide des tutoriels existants.

[gasche]

Il faut aussi faire attention au fait que la POO OCaml n'est pas triviale, parce qu'elle oblige les gens à réaliser que la plupart des opérations usuelles en POO, une fois qu'on doit les typer correctement, demandent un peu de réflexion.

Ça se manifeste par certains trucs vraiment pas intuitifs quand on débarque d'un autre langage POO et qu'on n'est pas bien habitué au système de typage. Il y a même des fonctionnalités qui n'existent quasiment que pour la POO, et qui donc (bien qu'intéressantes en soit) ne sont à priori pas connues par le programmeur OCaml lambda (huhu), comme par exemple le polymorphisme de second ordre.

Aborder la POO OCaml dans un cours quand on n'y est pas bien préparé, c'est assez casse gueule à mon avis. Ceci dit on peut aussi adopter une approche qui ne va pas en profondeur (comme certains tutos Haskell font pour les monades par exemple, même si ce n'est pas vraiment comparable) et avoir quelque chose qui marche correctement. Mais ça peut faire mal si le lecteur essaie des trucs qu'il ne devrait pas.

Après je ne connais pas LablGTK (j'espère que le binding Qt va sortir dans pas trop longtemps, et qu'il va laminer tous vos toolkits louches (GTK# pouah !), nah), donc je ne peux pas t'aider pour ce choix spécifique.

[InOCamlWeTrust]

D'accord avec bluestorm.

La couche objet de OCaml est une chose particulièrement intéressante et infiniment plus fine que le noyau stable du langage que tout le monde connaît. C'est vraiment pas facile à aborder, et mal expliqué, ou fait de façon trop scolaire, ça peut vite tourner à l'eau de boudin... C'est une chose entièrement à part, et pour moi, la seule qui vaille réellement le détour dans le langage.

Comme le dit bluestorm, il y a beaucoup de choses qui sont acquises dans la POO traditionnelle qui ne fonctionnent pas en OCaml : l'héritage sans sous-type (on peut hériter sans être un sous-type, et on peut être sous-type sans hériter), les objets fonctionnels (non modifiables, donc sans des set_machin_truc ()), le sous-typage explicite (on doit indiquer quand on attend un sous-type d'une classe dans le code), le mécanisme des interfaces de classe mélangé au mécanisme des modules (permettant d'aller beaucoup plus loin), et beaucoup d'autres trucs.

[SpiceGuid]

Il y a aussi quelques variants polymorphes en LablGtk2, mais rien de bien méchant, il me semble que c'est uniquement des constantes.

Je viens de jeter un oeil sur Gtkmm (binding GTK pour C++), apparemment ce serait cette conception qui a inspiré LablGtk2, toutefois le binding OCaml est bien plus élégant (et là je dis un grand à Jacques Garrigue ).

Je suis très partagé, d'un côté une interface laborieuse mais accessible, de l'autre une interface très convaincante mais qui concentre beaucoup des spécificités/avantages de OCaml.

Maintenant que je constate que chaque langage passe GTK+ à sa moulinette, je me dis pourquoi pas OCaml ? En tout cas j'ai abandonné l'idée qu'il fallait se rapprocher de GTK# (dont je n'ai personnellement rien à faire, comme de tout ce qui est .net/jvm).

Edit
Pour situer le contexte, voici un exemple de code LablGtk2 qui ouvre une fenêtre avec 2 boutons étiquettés "Hello..." et "World !" :

Code :

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

1
2
3
4
5
let win1 = GWindow.window ~title:"Hello..." ~border_width:6
let box1 = GPack.hbox ~packing:win1#add ()
let but1 = GButton.button ~packing:box1#pack ~label:"Hello"
let but2 = GButton.button ~packing:box1#pack ~label:"World !"
win1#show ()

Comme vous le voyez, dans son usage le plus élémentaire, l'utilisateur LablGtk2 n'est pas vraiment concerné par les difficultés liées au système de classes.

[gasche]

Tu devrais peut-être essayer, au lieu d'enseigner la POO "à part, avant", d'enseigner les deux en même temps. Ça ferait un enseignement de la POO moins poussé, moins organique et sûrement moins rigoureux, mais ça te protègerait peut-être aussi de ses éceuils (si tu dis que LablGTK les as évités).

[InOCamlWeTrust]

Il existe un problème fondamental avec la POO de OCaml : la difficulté que l'on a, au début, à écrire des classes non paramètrées sans erreur de type. Le problème, c'est que le type-checker de OCaml tendant à trop généraliser les types, entre autres dans les méthodes des classes, il faut, à chaque fois, ajouter un ou plusieurs constraint dans les classes pour lier les variables de type à l'intérieur-même de la classe (ce que je trouve complètement débile, car le programmeur n'est pas censé connaître l'ordre des noms de variables de type que le compilateur choisit automatiquement pour lui)...

Pour moi, ça a été la principale difficulté au début.