Miguel Moquillon wrote:

Laurent Deniau wrote:

Je ne connais pas Slate, mais je vais lire ca. Ca a effectivement l'air
interessant. Je vois neanmoins deja un probleme: la definition de la
classe declare les methodes qu'elle implemente,

En fait, les articles montrent la problématique du multi-dispatching avec
des langages procéduraux, objet à classes, et objets à prototypes. Ensuite,
ils donnent une solution pour ces derniers. Slate est un langage objet à
prototype et non à classes. Pour le multi-dispatching, Slate se focalise
sur la programmation par sujet au lieu de par verbe :)
Un exemple de syntaxe de Slate (arrayed.slate):
Array traitsWindow atSlotNamed: #traits1 put: Sequence traits.
Array traitsWindow atSlotNamed: #traits2 put: Collection traits.
Array traitsWindow atSlotNamed: #traits3 put: Mapping traits.
"Ensures that the primitive Array type has the behaviors and features of a
Sequence."

a@(Array traits) new &capacity: n
"Array capacity is its size, and newSize: is a primitive."
[a newSize: (n ifNil: [0])].

a@(Array traits) copy
[a clone].

a@(Array traits) arrayType [a].

Il est vrai que ça a l'aire barbare comme ça :)

Effectivement. Les gens senses utiliser mon code sont au mieux des physiciens avec qques connaissances de Fortran, C et parfois C++ (sic!).
D'autre part les plateformes sur lesquels ces codes vont atterir ont parfois comme meilleur compilateur gcc 2.7.2. Je parle meme pas de la dispo de Slate sur ces machines ;-)

Ici, Array est un objet à part entière et les traits définissent tous les
méthodes que peuvent supporter des prototypes. Les traits sont parents des
prototypes, et donc des prototypes (qui sont des objets) peuvent avoir le
même trait mais chacun donne une implémentation qui leur sont propres.

C'est le schema classique de construction objet-classe dans un langage a prototype il me semble.

On
peut considérer que les traits sont l'équivalent, dans une certaine mesure,
aux fonctions génériques.

Sont-ils independant de la classe? Il ne me semble pas. J'ai l'impression que c'est plutot sur un lien entre un prototype (objet) et un prototype (classe) qui permet de faire de la verification de type. Qqchose de tres proche des interfaces Java ou des Protocols d'ObjC, un concept que j'ai d'ailleurs repris dans OOC puisqu'il permet le decouplage des classes mais qui est inutile dans COS (le couplage n'existe pas).

Sinon, tes exemples sont intéressants. Toutefois j'aurais une question:
pourquoi faire par une surcouche à C ce qui existe déjà avec CLOS ?

Parce que CLOS (et surtout Lisp) est inexploitaple pour moi. Et l'interactivite de CL ne m'interesse pas (elle m'embete plus que ne me sert), je prefere un programme compile, independant et accessible par le plus grand nombre avec un bon makefile et des testsuites pour le developpement. Et de ce cote Common Lisp a encore de gros efforts a faire (en particulier dans le free source, je sais que certaine solutions commerciale offrent tout ca).

D'autre part, j'ecris essentiellement des bibliotheques et des programmes dans le domaine de l'analyse de donnees qui vont ensuite "atterir" sur des machines un peu partout dont je ne controle "presque" rien. Je sais seulement que c'est soit une Sun, soit un PC linux, soit un PC windows (pour l'instant) avec un compilateur C89 et que je dois etre compatible (entendre utlisable avec la plus grande simplicite) avec la pluspart des langages qui sont utilises par les sus-dit physiciens (essentiellement Fortran, C, Perl, Python, Java, Labview). Certains de ces programmes (qui doivent utiliser les memes bibliotheques) vont sur des serveurs ou on manipule alors plus centaines de Mo de donnees par analyse avec des structures de donnees optimisees en C, ce qui exclus Java et Lisp et presque tout les langages a base de GC, gros consomateurs de memoire et pas toujours tres rapides.

Quitte à faire une couche objet à C qui soit plus avancée à ce qui existe
déjà, pourquoi ne pas suivre son esprit, comme un peu avec C++, ou
légèrement plus éloigné, Obj; c'est à dire à prendre en compte sa nature
finalement procédurale du langage au lieu d'implémenter une syntaxe et un
mécanisme fonctionnel à la lisp/scheme ?

Je n'ai rien de fonctionnel dans tout ca (meme si les fermetures sont a portee de main), et ce que tu as vu est du pur C89, donc procedural. Ce n'est ni un nouveau langage, ni un preprocesseur, ni un compilateur. L'approche est donc similaire a ObjC tout en restant en C, c'est-a-dire ajouter une couche objet dynamique a C d'ou le nom de OOC (Object Oriented C) pour le premier qui s'inspire de Java et C++ et COS (C Object System) pour le second qui s'inspire de CLOS et ObjC. Tout ca est tres C-ish (?).

a+, ld.