Tu fais bien de rappeler ces choses là.
Les langages fonctionnelles et procédurales sont les deux plus grandes mais pas les seules. Les langages à inférence en sont d'autres.
Contrairement à ce que tu as écris, Smalltalk ne fait pas partie des langages fonctionnelles, ni non plus de ceux dits porcédurales. On pourrait dire, en tirant un peu sur la corde, que c'est à un langage à part qui exploite ces deux familles.
Tu dis que l'objet n'est pas si révolutionnaire que ça et ne permet pas plus de réutilisation que d'autres approches (modulaires par exemple). Tu tombes dans l'erreur même pour laquelle tu mes en garde les gens : l'objet n'est pas seulement une application des préceptes de son paradigme avec des outils le plus souvent limité.
Pourquoi l'objet ne parait pas si réutilisable ou révolutionnaire que ça ? Parce que l'on doit compter sur l'existant. Smalltalk a essayé de ne pas tenir compte de ce dernier et il en a payé les frais. Qu'est ce que c'est que cet existant ? C'est ce je j'ai appellé l'approche "classique" : des environnements découpés sous forme d'applications bien compartimentées. Finalement, l'objet ne s'applique quotidiennement qu'à contruire telle appli ou telle autre en objet. Mais les objets entre ces applis sont bien séparées et ne se connaissent pas. Pour palier à ce problème, on met en place nombre technos de communication inter-applications ou distribués.
L'objet c'est plus que ça. Sans parler de révolution, si on veut vraiment compter sur les avantages de l'objet : vraie réutilisation, extensibilité, etc. les objets ne doivent plus être enfermées dans des applis, mais doivent vivrent dans un environnement virtuel objet (ce qui ne signifie pas pour autant que cet environnement a été construit totallement de façon objet) distribué lui-même !
Cet environnement peut très bien être un ensemble matériel/VM ou une VM contruite sur un noyau d'OS ou tout autre chose. Dans cet environnement, la notion d'application n'existent pas. Seuls les objets existent. Cet environnement matient des catalogues d'objets, gèrent de façon transparente leur cycle de vie, leur répartition, leur persistance, etc.
Tu souhaites voir un film : de tel catalogue d'objet, tu prends l'objet "lecteur de vidéo". Cet objet utilise les services d'autres objets comme le codec MPEG par exemple et le driver vidéo correspondant à la carte vidéo de ta machine. Tu veux voir plusieurs films en même temps, tu clone l'objet et sur chacun tu visualises un film différent. Le lecteur vidéo t'interesse pour un un de tes programmes : très bien, dans spécifies que tel ou tel de tes objets communiquent avec lui. Etc.
Les environnements Smalltalk, sans pour autant aller très loin, implémentent ces idées. Pour te faire une idée, essaies Squeak par exemple : http://www.squeak.org(...)
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . En réponse au journal j'ai un rêve .... Évalué à 3.
Les langages fonctionnelles et procédurales sont les deux plus grandes mais pas les seules. Les langages à inférence en sont d'autres.
Contrairement à ce que tu as écris, Smalltalk ne fait pas partie des langages fonctionnelles, ni non plus de ceux dits porcédurales. On pourrait dire, en tirant un peu sur la corde, que c'est à un langage à part qui exploite ces deux familles.
Tu dis que l'objet n'est pas si révolutionnaire que ça et ne permet pas plus de réutilisation que d'autres approches (modulaires par exemple). Tu tombes dans l'erreur même pour laquelle tu mes en garde les gens : l'objet n'est pas seulement une application des préceptes de son paradigme avec des outils le plus souvent limité.
Pourquoi l'objet ne parait pas si réutilisable ou révolutionnaire que ça ? Parce que l'on doit compter sur l'existant. Smalltalk a essayé de ne pas tenir compte de ce dernier et il en a payé les frais. Qu'est ce que c'est que cet existant ? C'est ce je j'ai appellé l'approche "classique" : des environnements découpés sous forme d'applications bien compartimentées. Finalement, l'objet ne s'applique quotidiennement qu'à contruire telle appli ou telle autre en objet. Mais les objets entre ces applis sont bien séparées et ne se connaissent pas. Pour palier à ce problème, on met en place nombre technos de communication inter-applications ou distribués.
L'objet c'est plus que ça. Sans parler de révolution, si on veut vraiment compter sur les avantages de l'objet : vraie réutilisation, extensibilité, etc. les objets ne doivent plus être enfermées dans des applis, mais doivent vivrent dans un environnement virtuel objet (ce qui ne signifie pas pour autant que cet environnement a été construit totallement de façon objet) distribué lui-même !
Cet environnement peut très bien être un ensemble matériel/VM ou une VM contruite sur un noyau d'OS ou tout autre chose. Dans cet environnement, la notion d'application n'existent pas. Seuls les objets existent. Cet environnement matient des catalogues d'objets, gèrent de façon transparente leur cycle de vie, leur répartition, leur persistance, etc.
Tu souhaites voir un film : de tel catalogue d'objet, tu prends l'objet "lecteur de vidéo". Cet objet utilise les services d'autres objets comme le codec MPEG par exemple et le driver vidéo correspondant à la carte vidéo de ta machine. Tu veux voir plusieurs films en même temps, tu clone l'objet et sur chacun tu visualises un film différent. Le lecteur vidéo t'interesse pour un un de tes programmes : très bien, dans spécifies que tel ou tel de tes objets communiquent avec lui. Etc.
Les environnements Smalltalk, sans pour autant aller très loin, implémentent ces idées. Pour te faire une idée, essaies Squeak par exemple :
http://www.squeak.org(...)