Smalltalk est completement objet. Tout ce qu'on pouvait manipuler aves Smalltalk était indirectement instance d'une sous classe de Object : les entiers, les classes, les métaclasses, les booléens (true et false sont les deux instances uniques de la classe Boolean), l'objet vide, nul (instance de la class Null)...
Je ne connais pas de langage qui soit autant "objet" que smalltalk, à part peut-être certaines implémentations en lisp à l'interêt principalement éducatif.
Smalltalk est un tres, tres beau langage avec lequel j'ai pu m'amuser en entreprise il y a quelques années. Cela fait bien longtemps que je ne l'ai pas vu tourner. Je ne sais même pas s'il est encore mis à jour.
Les problemes de smalltalk étaient les suivants :
- Les concepts de l'interface graphique (MVC - Modele vue contrôleur) étaient tres puissants mais difficiles à apprehender
- Le systeme de classe étais un peu complexes pour un débutant. Chaque classe créée par le développeur donnait lieu à la création se sa méta-classe. La classe Collection était instance de la metaclass "class Collection". La classe Object Class étais sous-classe de la classe Metaclass, elle-même indirectement sous-classe de Object (comme toutes les classes de smalltalk). Comme vous voyez ce n'est pas simple...
- La machine virtuelle prenait beaucoup de mémoire. Elle incluait un environnement de développement, un débogeur et ln compilateur, tout tres tres bien faits mais gourmands...
- Le typage statique est inexistant ou presque. Ce n'est qu'à l'execution que la machine virtuelle peut détecter qu'une methode appellée n'existe pas. Pour couronner le tout, il est possible de faire de la meta-programmation, et d'appeller une méthode par son nom. Il n'est alors même plus possible en regardant le code de savoir quelle est le nom de la méthode appellée...
Le compilateur, comme tout l'environnement de développement, étais écrit en Smalltalk. Il produisait du code-ocyet (bytecode) interpreté par une machine virtuelle, coeur de l'architecture smalltalk. Les methodes primitives étaient les seules méthodes ne contenant pas de code smalltalk, et faisaient directement appel à la machine virtuelle. Par exemple, la méthode + de la classe Integer, ou les méthodes de bas niveau ayant trait à l'interface graphique.
Le concept de fermeture si cher à Lisp existait dans smalltalk. Ainsi le bloc [:x :y | (x>y) itTrue: [x] ifFalse: [y]] prends en entrée deux nombres et en renvoie le plus grand. Notez la méthode ifTrue:ifFalse, implementée dans la classe Boolean, qui prends deux blocs sans arguments en entrée et execute l'un ou l'autre selon la valeur de l'objet courant (self). Notez aussi que ce type de code est totalement générique : tant que la classe dont l'objet x est instance implémente la méthode >, accepte y comme argument, et renvoie un booléen, le code fonctionnera.
Les apples de méthodes étaient evidemment tous résolus dynamiquement, il n'étais pas question comme en c++ de devoir déclarer qu'une méthode était virtuelle. Toutes les méthodes étaient virtuelles sans exception. Les méthodes de type static étaient implémentées comme des méthodes standard dans la métaclasse. Par exemple, la méthode new de la classe "class Table" renvoyait une instance de la classe "Table", non sans lui avoir envoyé le message init (i.e. appellée la méthode init sur cet objet).
[^] # Re: révolutionnaire !
Posté par celastus . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 9.
Je ne connais pas de langage qui soit autant "objet" que smalltalk, à part peut-être certaines implémentations en lisp à l'interêt principalement éducatif.
Smalltalk est un tres, tres beau langage avec lequel j'ai pu m'amuser en entreprise il y a quelques années. Cela fait bien longtemps que je ne l'ai pas vu tourner. Je ne sais même pas s'il est encore mis à jour.
Les problemes de smalltalk étaient les suivants :
- Les concepts de l'interface graphique (MVC - Modele vue contrôleur) étaient tres puissants mais difficiles à apprehender
- Le systeme de classe étais un peu complexes pour un débutant. Chaque classe créée par le développeur donnait lieu à la création se sa méta-classe. La classe Collection était instance de la metaclass "class Collection". La classe Object Class étais sous-classe de la classe Metaclass, elle-même indirectement sous-classe de Object (comme toutes les classes de smalltalk). Comme vous voyez ce n'est pas simple...
- La machine virtuelle prenait beaucoup de mémoire. Elle incluait un environnement de développement, un débogeur et ln compilateur, tout tres tres bien faits mais gourmands...
- Le typage statique est inexistant ou presque. Ce n'est qu'à l'execution que la machine virtuelle peut détecter qu'une methode appellée n'existe pas. Pour couronner le tout, il est possible de faire de la meta-programmation, et d'appeller une méthode par son nom. Il n'est alors même plus possible en regardant le code de savoir quelle est le nom de la méthode appellée...
Le compilateur, comme tout l'environnement de développement, étais écrit en Smalltalk. Il produisait du code-ocyet (bytecode) interpreté par une machine virtuelle, coeur de l'architecture smalltalk. Les methodes primitives étaient les seules méthodes ne contenant pas de code smalltalk, et faisaient directement appel à la machine virtuelle. Par exemple, la méthode + de la classe Integer, ou les méthodes de bas niveau ayant trait à l'interface graphique.
Le concept de fermeture si cher à Lisp existait dans smalltalk. Ainsi le bloc [:x :y | (x>y) itTrue: [x] ifFalse: [y]] prends en entrée deux nombres et en renvoie le plus grand. Notez la méthode ifTrue:ifFalse, implementée dans la classe Boolean, qui prends deux blocs sans arguments en entrée et execute l'un ou l'autre selon la valeur de l'objet courant (self). Notez aussi que ce type de code est totalement générique : tant que la classe dont l'objet x est instance implémente la méthode >, accepte y comme argument, et renvoie un booléen, le code fonctionnera.
Les apples de méthodes étaient evidemment tous résolus dynamiquement, il n'étais pas question comme en c++ de devoir déclarer qu'une méthode était virtuelle. Toutes les méthodes étaient virtuelles sans exception. Les méthodes de type static étaient implémentées comme des méthodes standard dans la métaclasse. Par exemple, la méthode new de la classe "class Table" renvoyait une instance de la classe "Table", non sans lui avoir envoyé le message init (i.e. appellée la méthode init sur cet objet).