[HS Total] [Objet ou pas?]

Bonjour,
[coupé]

Non, ne coupez pas !-)

Imagines une porte.
Tu appelles une fonction ouvre() et une fonction ferme() en passant en
paramètre la porte. Moais.
Tu as à disposisiton un objet "porte". Tu appelles des services de la
fabrique de cet objet (classe ou autre) par l'intermédiaire de
l'objet, porte->ouvrir() et porte->fermer() par exemple.

Ce que tu montres comme différence n'est que syntaxique, pas sémantique.
Dans d'autres langages objets (CLOS par exemple), la syntaxe d'envoi de
message est bien du genre message(destinataire, ...).

Certes, mais de mon point de vue, je pense que syntaxe et sémantique
ne sont pas complètement dissociables pour faire de l'objet : quand on
a généralement affaire à une expression qui prend en paramètres une
autre expression entre parenthèses, on pense prioritairement au
fonctionnel, comme en maths.

s/on/tu/

D'une part, si dans ton exemple, ce n'était pas le mot
"message(destinataire, messageAenvoyer...)" ou
"envoieMessage(destinataire, messageAenvoyer..)" mais par exemple un
verbe comme "appliquerQqChose(destinataire, args...)", on n'aurait
beaucoup de mal à cerner où est l'objet là-dedans,

Il est clair que la syntaxe la plus courante reste 'objet message args',
qui est plus proche du "sujet verbe complément", et donc exprime mieux
(sémantiquement) le concept.

Ce que je voulais souligner en l'occurrence est que ce n'est pas la
syntaxe qui importe - d'autant que cette même syntaxe (obj->member)
existe déjà en C avec une sémantique quelque peu différente - et il me
semble que le "détournement" de cette syntaxe en C++ puis en Java etc
n'est pas pour rien dans la difficulté qu'on les débutants en OO à
comprendre la différence *sémantique* entre appel de fonction/méthode et
envoi de message (le second *pouvant* entrainer le premier).

tout en sachant
que le mot message a une signification claire dans le monde objet (cf.
diag. séquence et collaboration en UML).

Le mot 'message' a une signification précise dans le monde objet, bien
avant et totalement indépendemment de UML.

D'autre part, une syntaxe "message(destinataire, message...)" implique
de passer en paramètre le message à envoyer,

(NB : ce n'est pas une syntaxe que j'ai donné en example.)

ce qui est moins
évident pour comprendre des notions comme le polymorphisme, AMHA.

Parce que tu tends à confondre message et sélection de méthode AMHA. Le
polymorphisme, *dans ce contexte*, consiste en ce que différent objets
puissent sélectionner des méthodes (comportements) différents en
réaction à un même message. Différencier message et sélection de méthode
aide AMHA à comprendre le principe. Après, la façon dont c'est
implémenté - et accessoirement la syntaxe - dans tel ou tel langage,
c'est un point de détail (en ce qui concerne l'OO, pas en ce qui
concerne le langage !-)

<op>
Ce que tu décrit ici est un ADT (Abstract Data Type, ou Type de Donnée
Abstrait pour les anglophobes). C'est, techniquement, l'"ancêtre" de
l'objet.
La différence fondamentale, c'est le polymorphisme, qui s'appuie sur la
notion de message. Dans ton exemple, tu appelles explicitement une
fonction déterminée. En objet, tu envoie un message à un objet, charge à
lui de déterminer la fonction implémentant la réponse adaptée à ce
message. Ceci permet à des objets de différents types de répondre,
chacun à sa façon, au même message.

Oui, j'ai oublié d'introduire par exemple un objet porteCoulissante et
un objet porteAvecGonds partageant des caractéristiques communes avec
l'objet porte, ceci afin de montrer que des services communs offerts
comme ouvrir() et fermer() peuvent aussi s'y appliquer avec un
polymorphisme d'héritage.

Héritage de type ou d'implémentation ?-)

Un meilleur exemple serait de présenter également un objet "livre" et un
objet "robinet". Eux aussi comprennent les messages "ouvrir" et
"fermer", et ce ne sont clairement pas des sous-classes de "porte". Un
livre et une porte appartiennent-ils au même type ? (ou "à un" même
type, ce qui est différent) ? La réponse dépend évidemment de la
définition de "type", et il n'y a clairement pas consensus sur cette
définition.

Dans certains langages (langages à prototypes comme Self ou Javascript,
ou langages très dynamiques comme Python), il est possible de modifier
dynamiquement l'interface et/ou l'implémentation d'un objet donné. En
Python, il est possible de modifier dynamiquement la classe d'un objet
donné, et de modifier dynamiquement l'interface et/ou l'implémentation
d'une classe (une classe étant elle-même un objet), cette modif étant
immédiatement répercutée sur toutes les instances de ladite classe.

Dans ces conditions, comment définir "le" type d'un objet donné ?

(snip)

Pa mal, pas mal, mais faut passer au C++ dans ce cas là !!

Pourquoi faire ?

Justement pour pallier au manque de souplesse (ajout dynamique de types
et peu de modifications de code) que tu cites à peine plus haut avec
l'ADT, sans à avoir à réinventer la roue

Oui, mais pourquoi C++ ? Franchement, si c'est pour faire de l'objet,
Smalltalk, Ruby, Python ou CLOS (quoique... après réflexion, je retire
CLOS) sont probablement plus instructifs - surtout si l'OP s'interroge
sur la différence fondamentale entre un struct et un objet.

et garder une syntaxe
proche du C.

Dans ce cas, Objective-C

Si changer de syntaxe ne gêne pas l'OP, vive Ada !!

<sans vouloir troller>
Encore un langage procédural à typage statique avec une surcouche objet.
Si l'OP veut vraiment comprendre les concepts de base de l'OO, autant
choisir un langage 1/ plus light (plus rapide à apprendre, plus facile à
mettre en oeuvre) et 2/ plus clairement objet.
</sans vouloir troller>

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '***@xiludom.gro'.split('@')])"

Miguel Moquillon

2005-11-29 14:39:50 UTC

Bonjour, je peux mettre mon grain de sels ? :)

Post by bruno at modulix
Il est clair que la syntaxe la plus courante reste 'objet message args',
qui est plus proche du "sujet verbe complément", et donc exprime mieux
(sémantiquement) le concept.

Tout à fait. Ceci vient en plus du monde Smalltalk. Pour parler syntaxe, je
trouve même leur syntaxe d'envoie de messages à un objet bcp plus
pertinent
que les autres langages objet.

Post by bruno at modulix
Un meilleur exemple serait de présenter également un objet "livre" et un
objet "robinet". Eux aussi comprennent les messages "ouvrir" et
"fermer", et ce ne sont clairement pas des sous-classes de "porte". Un
livre et une porte appartiennent-ils au même type ? (ou "à un" même
type, ce qui est différent) ? La réponse dépend évidemment de la
définition de "type", et il n'y a clairement pas consensus sur cette
définition.

Ce n'est pas vrai (ou totalement vrai). Il y a actuellement deux
définitions
possibles du typage:
- celui, plus ancienne, de Liskov, dans lequel un type définit l'interface
de l'objet (donc l'héritage est centré sur le sous-typage (je ne parle pas
de l'héritage d'implémentation qui est autre chose)),
- celui, plus actuelle, de Cook, dans laquelle une classe définit une
famille polymorphique de types (donc l'héritage est centré sur la
sous-classification (ça se dit en français ce machine ?)).

Post by bruno at modulix
Dans certains langages (langages à prototypes comme Self ou Javascript,
ou langages très dynamiques comme Python), il est possible de modifier
dynamiquement l'interface et/ou l'implémentation d'un objet donné.

Quand tu modifies l'interface de ton objet, les modifs doivent se
répercuter
sur l'ensemble des sous-types. Si non, alors mauvais langage car il
n'applique pas correctement les relations mathématiques du typage.

Par contre, effectivement, la modif de l'implémentation d'un service dans
une classe d'objet doit se répercuter sur l'ensemble des instances de la
classe.

De toute façon, AMHA, les langages objet à types (C++, Java, ...) ou à
classes (Smalltalk, Eiffel, ...) implémentent de façon complexe les
concepts et principes de l'objet. Avec les langages objet à prototypes, je
pense que nous arrivons à une simplification des choses, ce qui permet de
se concentrer sur les principes même de l'objet et non sur des détails
techniques ou théoriques de ceux-ci (particulièrement les relations
typage-classification).

bruno at modulix

2005-11-29 18:22:15 UTC

Post by Miguel Moquillon
Bonjour, je peux mettre mon grain de sels ? :)

<hs>
C'est mon newsreader qui est dans les choux, ou le tien qui délire sur
l'encodage ?
</hs>

Post by bruno at modulix
Il est clair que la syntaxe la plus courante reste 'objet message args',
qui est plus proche du "sujet verbe complÃ©ment", et donc exprime mieux
(sÃ©mantiquement) le concept.

Tout Ã fait. Ceci vient en plus du monde Smalltalk. Pour parler syntaxe, je
trouve mÃªme leur syntaxe d'envoie de messages Ã un objet bcp plus
pertinent
que les autres langages objet.

Post by bruno at modulix
Un meilleur exemple serait de prÃ©senter Ã©galement un objet "livre" et un
objet "robinet". Eux aussi comprennent les messages "ouvrir" et
"fermer", et ce ne sont clairement pas des sous-classes de "porte". Un
livre et une porte appartiennent-ils au mÃªme type ? (ou "Ã un" mÃªme
type, ce qui est diffÃ©rent) ? La rÃ©ponse dÃ©pend Ã©videmment de la
dÃ©finition de "type", et il n'y a clairement pas consensus sur cette
dÃ©finition.

Ce n'est pas vrai (ou totalement vrai).

Bin pourtant si.

Post by Miguel Moquillon
Il y a actuellement deux
dÃ©finitions
- celui, plus ancienne, de Liskov, dans lequel un type dÃ©finit l'interface
de l'objet (donc l'hÃ©ritage est centrÃ© sur le sous-typage (je ne parle pas
de l'hÃ©ritage d'implÃ©mentation qui est autre chose)),
- celui, plus actuelle, de Cook, dans laquelle une classe dÃ©finit une
famille polymorphique de types (donc l'hÃ©ritage est centrÃ© sur la
sous-classification (Ã§a se dit en franÃ§ais ce machine ?)).

Post by bruno at modulix
Dans certains langages (langages Ã prototypes comme Self ou Javascript,
ou langages trÃšs dynamiques comme Python), il est possible de modifier
dynamiquement l'interface et/ou l'implÃ©mentation d'un objet donnÃ©.

Quand tu modifies l'interface de ton objet, les modifs doivent se
rÃ©percuter
sur l'ensemble des sous-types. Si non, alors mauvais langage car il
n'applique pas correctement les relations mathÃ©matiques du typage.

J'ai bien parlé d'un *objet*, pas d'une classe (en faisant abstraction
du fait que dans certains langages, les classes soient elles-mêmes des
objets).

Les "relations mathématiques du typage", c'est bien beau, mais ça a quel
sens dans un langage à prototype ?-)

Post by Miguel Moquillon
Par contre, effectivement, la modif de l'implÃ©mentation d'un service dans
une classe d'objet doit se rÃ©percuter sur l'ensemble des instances de la
classe.
De toute faÃ§on, AMHA, les langages objet Ã types (C++, Java, ...) ou Ã
classes (Smalltalk, Eiffel, ...) implÃ©mentent de faÃ§on complexe les
concepts et principes de l'objet. Avec les langages objet Ã prototypes, je
pense que nous arrivons Ã une simplification des choses, ce qui permet de
se concentrer sur les principes mÃªme de l'objet et non sur des dÃ©tails
techniques ou thÃ©oriques de ceux-ci (particuliÃšrement les relations
typage-classification).

Oui et non, cf ci-dessus. On peut presque dire que *les* types d'un
objet sont définis par l'utilisation effective (cf les mécanismes
d'inférence de type - ou plus simplement le duck-typing !-).

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '***@xiludom.gro'.split('@')])"

Miguel Moquillon

2005-11-30 10:16:26 UTC

Post by bruno at modulix

Post by Miguel Moquillon
Bonjour, je peux mettre mon grain de sels ? :)

<hs>
C'est mon newsreader qui est dans les choux, ou le tien qui délire sur
l'encodage ?
</hs>

Non, c'est mon client qui délire. En fait je suis en UTF-8 mais le groupe
fr.comp.objet ne supporte pas l'UTF-8. J'ai du faire un conversion qui ne
s'est pas bien passe.
Je presente mes excuses et je vais dorenavant, comme dans le bon vieux
temps, eviter d'utiliser les caracteres accentues.

Post by bruno at modulix

Post by Miguel Moquillon
Ce n'est pas vrai (ou totalement vrai).

Bin pourtant si.

Ben non :)
En fait, il faut bien faire la distinction entre le typage et son
implementation (assez pauvre la plupart du temps) dans les langages objets.

Post by bruno at modulix
J'ai bien parlé d'un *objet*, pas d'une classe (en faisant abstraction
du fait que dans certains langages, les classes soient elles-mêmes des
objets).

Ha ok. Dans ce cas effectivement, seul l'objet se voit attribuer les
nouveaux proprietés.

Post by bruno at modulix
Les "relations mathématiques du typage", c'est bien beau, mais ça a quel
sens dans un langage à prototype ?-)

Dans un langage objet a prototype ? Pareil qu'avant si ce n'est que l'on ne
se casse plus la tete avec les notions de classes et de types dans le
langage

Post by bruno at modulix

Post by Miguel Moquillon
Avec les langages objet Ã prototypes,
je
pense que nous arrivons Ã une simplification des choses, ce qui permet
de se concentrer sur les principes mÃªme de l'objet et non sur des
dÃ©tails techniques ou thÃ©oriques de ceux-ci (particuliÃšrement les
relations typage-classification).

Oui et non, cf ci-dessus. On peut presque dire que *les* types d'un
objet sont définis par l'utilisation effective (cf les mécanismes
d'inférence de type - ou plus simplement le duck-typing !-).

Il me semble, a tes propos, que tu melanges le typage avec ses differentes
implementations dans un langage.

Note: dans mes propos, je reste dans le domaine des langages objets (des
langages vraiment objet). Donc je ne tiens pas compte des langages comme
Javascript ou C par exemple.

zwetan

2005-12-28 06:12:52 UTC

"Miguel Moquillon" wrote:
[snip]

Post by Miguel Moquillon
Note: dans mes propos, je reste dans le domaine des langages objets (des
langages vraiment objet). Donc je ne tiens pas compte des langages comme
Javascript ou C par exemple.

et pourquoi JavaScript ne serait pas vraiment objet ???

concernant le duck typing, le typage et la classification avec un un langage
basé sur les prototype
(ou basé sur les objets donc, comme JavaScript)

une des thèses de Daniel Bardou m'a pas mal fait réfléchir
http://www.inrialpes.fr/romans/people/bardou/English/publications.html

Étude des langages à prototypes, du mécanisme de délégation, et de son
rapport à la notion de point de vue.
http://www.inrialpes.fr/romans/people/bardou/English/P_Bard98a.html

et maintenant avec cette notion de point de vue j'ai tendance a considérer
le typage
des instances d'objet JavaScript comme des relations
"is-like-a"/"has-like-a" au lieu
du classique "is-a"/"has-a"

C'est sur le "duck typing" reduit la claire identification (ou le
cloisonnement) du type de l'objet,
mais amha cela apporte d'autres avantages et je trouve cela plus souple a
l'utilisation :).

Dans le cas d'une classe "Porte" cela permet de directement créer un objet
"PorteCoulissante"
qui est "is-like-a" un objet "Porte" sans forcément créer une class
"PorteCoulissante".

Qu'est ce qui te fait dire que JavaScript n'est pas vraiment objet ?

zwetan

Miguel Moquillon

2006-01-03 10:12:14 UTC

Post by zwetan
[snip]

et pourquoi JavaScript ne serait pas vraiment objet ???

Le question serait plutôt : pourquoi JavaScript ne serait pas vraiment un
langage objet ?
Je répondrais par cette autre question :
"Pourquoi le C ne serait pas vraiment un langage objet ?"

Et je rajouterais ceci:
Ce n'est pas parce qu'avec un langage quelconque on puisse, par force
contorsion, à "faire de l'objet", que ce langage soit lui-même un langage
objet.
De même, ce n'est pas parce que tu utilises un langage objet que tu fais
réellement de l'objet.

Je pense qu'avant d'écrire une réponse, il faut d'abord répondre à ces
questions:
- qu'est ce que le paradigme Objet ? Que sont ces principaux concepts
sous-jacent ?
- qu'est-ce q'un langage objet ?

Miguel

Marc Boyer

2006-01-03 09:43:21 UTC

Post by Miguel Moquillon
Je pense qu'avant d'écrire une réponse, il faut d'abord répondre à ces
- qu'est ce que le paradigme Objet ? Que sont ces principaux concepts
sous-jacent ?

C'est dans un bouquin sur le temps réel que j'ai trouvé la
première définition qui me satisfasse: elle offre deux niveaux,
ADT (Abstract Data Type) et OOP.

L'ADT fournit principalement l'abstraction, ie découple
l'interface de l'implémentation d'un type.

La POO est un ADT enrichit par:
- une relation de sous-typage / extendabilité de types
- gestion automatique de l'initialisation et la destruction d'objet
- liaison tardive / polymorphisme dynamique

Post by Miguel Moquillon
- qu'est-ce q'un langage objet ?

Un langage qui offre un support pour ces choses là ?

Marc Boyer

--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain

Miguel Moquillon

2006-01-03 11:14:50 UTC

Post by Marc Boyer
C'est dans un bouquin sur le temps réel que j'ai trouvé la
première définition qui me satisfasse: elle offre deux niveaux,
ADT (Abstract Data Type) et OOP.

De plus, ce qui est intéressant dans l'ADT, et que l'on ne retrouve que dans
très peu de langages objets, est la définition de conditions (pré et
post-conditions des opérations) et des invariants.

Miguel

Marc Boyer

2006-01-03 10:49:20 UTC

Post by Marc Boyer
C'est dans un bouquin sur le temps réel que j'ai trouvé la
première définition qui me satisfasse: elle offre deux niveaux,
ADT (Abstract Data Type) et OOP.

Pre/post, j'ai oublié de mentionné tellement ça me paraît évident,
(j'en fait même en procédural) mais en effet, rappelons le.

L'invariant, c'est sujet à discussion: l'invariant est
souvent lié à l'implémentation, et dans les rares cas où
il ne l'est pas (genre size()<=capacity()), je pense qu'on
pourrait le déduire des pré/post.

Mais pour moi, POO => pre/post + invariants.
- Pre/post car ce devrait être dans le procédural.
- Invariant, car justement, le role de l'initialiseur,
c'est de mettre en place l'invariant.

Après, pourquoi si peu de support dans les langages ?
C'est une longue discussion. Je pense que si tout le monde
est d'accord pour dire qu'il faudrait énoncer cela,
certains discutent sur le coût de leur vérification,
mais le pire, c'est que faire si on détecte une violation ?

Marc Boyer

--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain

zwetan

2006-01-04 14:47:09 UTC

Post by Miguel Moquillon
Le question serait plutôt : pourquoi JavaScript ne serait pas vraiment un
langage objet ?
"Pourquoi le C ne serait pas vraiment un langage objet ?"
Ce n'est pas parce qu'avec un langage quelconque on puisse, par force
contorsion, à "faire de l'objet", que ce langage soit lui-même un langage
objet.
De même, ce n'est pas parce que tu utilises un langage objet que tu fais
réellement de l'objet.
Je pense qu'avant d'écrire une réponse, il faut d'abord répondre à ces
- qu'est ce que le paradigme Objet ? Que sont ces principaux concepts
sous-jacent ?
- qu'est-ce q'un langage objet ?

la bonne question serait

Quelle est _ta_ définition d'un langage vraiment objet ?

par rapport a ce que tu disais sur
| > Note: dans mes propos, je reste dans le domaine des langages objets (des
| > langages vraiment objet).

apparemment tu te bases plus sur la théorie que sur l'usage d'un langage,
ce qui est dommage amha.

zwetan

Miguel Moquillon

2006-01-04 16:03:29 UTC

Post by Miguel Moquillon
Je pense qu'avant d'écrire une réponse, il faut d'abord répondre à ces
- qu'est ce que le paradigme Objet ? Que sont ces principaux concepts
sous-jacent ?
- qu'est-ce q'un langage objet ?

la bonne question serait
Quelle est _ta_ définition d'un langage vraiment objet ?

Non.
La définition _usuelle_ et centrale de l'objet est celle donnée, par
exemple, par Marc, et comme il l'a dit, un langage objet est un langage qui
offre un support aux principes centraux du paradigme objet. Au vue de ceci,
je suis désolé, mais JavaScript n'offre pas ce support.

Post by zwetan
apparemment tu te bases plus sur la théorie que sur l'usage d'un langage,
ce qui est dommage amha.

Au contraire, ce qui est dommage est d'avoir une connaissance d'un sujet que
par l'usage d'un outil limité. Les langages, quelqu'ils soient, ne sont que
des outils plus ou moins limités pour exprimer, composer un système objet.
Pour bien appréhender le développement objet, AMHA, il faut de toute façon
passer par la "théorie", sachant qu'elle est en constant évolution.
Je m'appuie sur les/des concepts du paradigme objet et sur mon expérience
pour réaliser un système, dans la mesure du possible, objet et de façon
aussi objet. Les langages m'aident ou non à réaliser au mieux cet objectif.
Et non l'inverse.

Miguel

zwetan

2006-01-05 03:17:53 UTC

Post by zwetan
la bonne question serait
Quelle est _ta_ définition d'un langage vraiment objet ?

je ne suis pas du tout d'accord

mais c'est surtout que les principes centraux du paradigme objet
je les definis comme cela

- abstraction
- encapsulation
- modularité
- hierarchie

et JavaScript supporte facilement ces 4 principes

Post by zwetan
apparemment tu te bases plus sur la théorie que sur l'usage d'un langage,
ce qui est dommage amha.

Au contraire, ce qui est dommage est d'avoir une connaissance d'un sujet que
par l'usage d'un outil limité.

c'est _toi_ qui pense que JavaScript est limité
et je peux te jurer que non :)

si tu regardes l'evolution de langages comme Java ou C#
tu verras qu'il y a bcp de concepts dynamiques qui leurs sont rajoutés
"apres coup"
ces meme concepts dynamiques existant deja en JavaScript

Post by Miguel Moquillon
Les langages, quelqu'ils soient, ne sont que
des outils plus ou moins limités pour exprimer, composer un système objet.
Pour bien appréhender le développement objet,

on est d'accord

Post by Miguel Moquillon
AMHA, il faut de toute façon
passer par la "théorie", sachant qu'elle est en constant évolution.

je ne dis pas qu'il ne faut pas de théorie, mais bon
les langages aussi sont en constantes evolution

des langages comme Python et JavaScript n'ayant pas de typage statique
au depart se tournent vers de l'annotation de type par exemple

Post by Miguel Moquillon
Je m'appuie sur les/des concepts du paradigme objet et sur mon expérience
pour réaliser un système, dans la mesure du possible, objet et de façon
aussi objet. Les langages m'aident ou non à réaliser au mieux cet objectif.
Et non l'inverse.

avec un langage comme JavaScript on est au plus pres des objets,
ce n'est pas un mal et cela n'empeche pas du tout (au contraire je trouve
que c'est pls facile)
la realisation de systemes objets

meme si JavaScript a un model objet basé sur les prototype et la delegation
au contraire des plus traditionnels models objets basés sur les classes
ce sont juste 2 approches differentes a l'orientation objet

quelques references

"Classes vs Prototypes " OOPSLA 89
http://www.laputan.org/reflection/warfare.html

"Classes versus Prototypes in Object-Oriented Languages" ACM/IEEE 86
http://www.cs.washington.edu/research/constraints/object-oriented/fjcc-86.html

"Is JavaScript an Object-Oriented Language?" Dr Dobb's Journal 2001
http://www.ddj.com/documents/s=1697/ddj0108l/

"Object-Based Languages" sern CA (software engineering research network)
http://sern.ucalgary.ca/courses/SENG/609.03/W98/Abadi/AbadiCh4.html

la derniere reference que je pense serieuse est tres claire amha
"OO Languages need not be based on classes.
Object may be thought of as a more primitive concept than class:
* Object-based languages may be just a powerful as class-based languages,
and may even simulate classes"

trad:
Les langages OO n'ont pas besoin d'etre basés sur les classes.
Les objets peuvent etre considérés comme un concept plus primitif que les
classes.
* Les langages basés sur les objets pourraient bien etre aussi puissant que
les langages basés sur les classes, et pourraient meme simuler les classes

et a propos de references
Waldemar Horwat une des personnes qui a beaucoup contribué a la
standardisation et au design de JavaScript, lis ce genre de choses
http://www.mozilla.org/js/language/bibliography.html
ce qui peut donner une idée par quoi le desing de JavaScrip a été influencé.

zwetan

Marc Boyer

2006-01-05 09:00:48 UTC

Post by zwetan
Quelle est _ta_ définition d'un langage vraiment objet ?

Non.
La définition _usuelle_ et centrale de l'objet est celle donnée, par
exemple, par Marc, et comme il l'a dit, un langage objet est un langage

qui

Post by Miguel Moquillon
offre un support aux principes centraux du paradigme objet. Au vue de

ceci,

Post by Miguel Moquillon
je suis désolé, mais JavaScript n'offre pas ce support.

je ne suis pas du tout d'accord
mais c'est surtout que les principes centraux du paradigme objet
je les definis comme cela
- abstraction
- encapsulation
- modularité
- hierarchie

Pourrais-tu préciser ce que tu entends par ces 4 termes ?
Parce qu'à mon sens, les 3 premiers sont compris dans les ADT,
et je ne comprends pas trop le 4ème.

Post by zwetan
"Object-Based Languages" sern CA (software engineering research network)
http://sern.ucalgary.ca/courses/SENG/609.03/W98/Abadi/AbadiCh4.html

Elle est très claire celle là en effet.

Marc Boyer

--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain

Miguel Moquillon

2006-01-05 10:48:19 UTC

Je n'ai pas trop de temps, aussi je répond assez rapidement. Je suis désolé
par avance pour toutes fautes d'orthographes ou autres erreurs.

Post by Miguel Moquillon
je suis désolé, mais JavaScript n'offre pas ce support.

je ne suis pas du tout d'accord
mais c'est surtout que les principes centraux du paradigme objet
je les definis comme cela
- abstraction
- encapsulation
- modularité
- hierarchie

Je suppose que quand tu parles de hiérarchie, tu penses au typage ou à la
classification selon le typage de Liskov ou celui de Cook.
Sinon, pour faire simple et court, abstraction + encapsulation + modularité
est décrit par un seul principe : l'objet.
Les concepts fondamentaux de l'objet sont à mes yeux, pour résumer:
- ADT,
- sous-typage ou classification (sachant que la classification est pour moi
et par expérience la meilleur expression du typage en objet),
- polymorphisme

Post by zwetan
et JavaScript supporte facilement ces 4 principes

JavaScript comme C peuvent supporter, autrement dit, donner le moyen de les
implémenter, ces principes avec plus ou moins du boulot. Ce qui ne veut pas
dire qu'ils _offrent_ le support de ces principes.
Ce n'est pas parce que en javaScript tu as Object que ceci en fait un
langage objet. En tout cas, mon expérience avec me confirme dans cette
appréciation.

Post by zwetan
c'est _toi_ qui pense que JavaScript est limité
et je peux te jurer que non :)

Tout langage est de toute façon limité. Le seul que je connaisse et qui
puisse lever /naturellement/ ses propres limitations est Smalltalk.

Post by zwetan
si tu regardes l'evolution de langages comme Java ou C#
tu verras qu'il y a bcp de concepts dynamiques qui leurs sont rajoutés
"apres coup"
ces meme concepts dynamiques existant deja en JavaScript

Je ne remet pas en cause les concepts dynamique. Si tu parles des types
dynamiques dans les langages objet, je suis même convaincu que c'est un
moyen d'expression qui te permet d'écrire un système objet avec bcp de
facilité et de souplesse.

Post by zwetan
les langages aussi sont en constantes evolution

Oui je suis d'accord

Post by zwetan
des langages comme Python et JavaScript n'ayant pas de typage statique
au depart se tournent vers de l'annotation de type par exemple

mouais bof (c'est mon opinion)
J'attends de voir...

Post by zwetan
avec un langage comme JavaScript on est au plus pres des objets,
ce n'est pas un mal et cela n'empeche pas du tout (au contraire je trouve
que c'est pls facile)
la realisation de systemes objets

On est plus près de l'objet avec Eiffel que JavaScript, avec Python que
JavaScript.

Post by zwetan
meme si JavaScript a un model objet basé sur les prototype et la
delegation au contraire des plus traditionnels models objets basés sur les
classes ce sont juste 2 approches differentes a l'orientation objet

Je suis d'accord que les classes ou les prototypes sont deux approches du
paradigme objet.
Maintenant, JavaScript est un langage à prototypes de fonctions et non
d'objets. Pour avoir une vision réelle de ce qu'est un langage objet à
prototypes, cf. Self, Slate, io, lisaac, etc.

Post by zwetan
quelques references
[ ... ]

Je lirais ces références un peu plus tard (il est possible, mise à part
celui sur JavaScript, comme pour le dernier, que je les ai déjà lu). Quant
à la dernière référence, ce n'est pas pour autant que cela fait de
JavaScript un langage objet. Il existe plusieur formes de prototypage comme
il existe plusieurs formes de modules ou types structurés. Dire que
JavaScript est un langage objet revient à dire que Ada 83 est aussi un
langage objet sous prétexte qu'il supporte la modularité et le
sous-typage !

Mais peut-être qu'à la lecture de l'article sur JavaScript, je changerais
mon opinion sur celui-ci.

Miguel

Marc Boyer

2006-01-05 10:52:54 UTC

Post by zwetan
c'est _toi_ qui pense que JavaScript est limité
et je peux te jurer que non :)

Tout langage est de toute façon limité. Le seul que je connaisse et qui
puisse lever /naturellement/ ses propres limitations est Smalltalk.

Pour information générale (sans lien direct avec ce qui
nous intéresse), un autre langage vraiment général,
c'est maude.

On peut y batir une tour infinie de meta niveaux...
Pour l'instant, je découvre le niveau 0, mais la doc
montre bien qu'on peut monter tant qu'on veut.

Marc Boyer

--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain

zwetan

2006-01-07 10:26:57 UTC

Post by Miguel Moquillon
Je n'ai pas trop de temps, aussi je répond assez rapidement. Je suis désolé
par avance pour toutes fautes d'orthographes ou autres erreurs.

bah pas mieux j'avais pas le temps du tout ;)

Post by zwetan
- abstraction
- encapsulation
- modularité
- hierarchie

Je suppose que quand tu parles de hiérarchie, tu penses au typage ou à la
classification selon le typage de Liskov ou celui de Cook.

entre autre

Post by Miguel Moquillon
Sinon, pour faire simple et court, abstraction + encapsulation + modularité
est décrit par un seul principe : l'objet.
- ADT,
- sous-typage ou classification (sachant que la classification est pour moi
et par expérience la meilleur expression du typage en objet),
- polymorphisme

le probleme pour moi avec l'ADT c'est qu'on donne une trop grand importance
au type dans le sens de son identité

je prefere rester sur les 4 principes precedents et de ces 4 principes
decouler d'autres principes comme le polymorphisme

ou comme ces autres principes:

- the open closed principle
- the Liskov sustitution principle
- the dependency inversion principle
- the reuse release equivalency principle
etc...

Post by zwetan
et JavaScript supporte facilement ces 4 principes

le type objet en Javascript est un type primitif

et une fois de plus tu ne definis pas ce qu'est vraiment un langage objet
pour toi

[snip]

On est plus près de l'objet avec Eiffel que JavaScript, avec Python que
JavaScript.

et pourquoi ?

là tu affirmes quelquechose tu ne donnes pas d'arguments qui soutiennent
cela

humm tu simplifies bcp trop JavaScript amha en disant cela

oui certes les constructeurs objet sont des fonctions,
mais leur mecanisme est objet

en fait chaque fonction est un constructeur objet en puissance
car des que l;ont definis une fonction celle-ci a automatiquement
une propriete prototype heritant par delegation de l'objet prototype

mais en soit l'objet Function est un objet, qui lui aussi hrite de l'objet
Object
le concept est assez puissant amha :)

Post by zwetan
quelques references
[ ... ]

ces articles disent principalement que etre basé sur les prototypes
permet autant sinon plus que etre basé sur les classes

et meme si il existe plusieurs formes de prototypage (avec ou sans traits
par exemple)
reste que le fait d'etre basé sur les prototypes, meme dans la plus basique
des definitions,
permet de faire de l'orienté objet.

apres on en revient au meme probleme: etre un langage qui permet de faire de
l'orienté objet
ou etre un langage objet
et sur ce je repette ma question

quel est pour toi un langage vraiment objet ?

Post by Miguel Moquillon
Mais peut-être qu'à la lecture de l'article sur JavaScript, je changerais
mon opinion sur celui-ci.

peut-etre mais apparement tu as deja des idées tres arretés sur JavaScript

zwetan

Miguel Moquillon

2006-01-09 09:41:43 UTC

Post by zwetan
quel est pour toi un langage vraiment objet ?

Il me semble pourtant l'avoir écrit.
Un langage objet est un langage qui supporte les caractéristiques centrales
du paradigme objet, et principalement:
- encapsulation,
- typage (Liskov ou Cook), qu'il soit statique, dynamique ou par inférence,
- définition d'objets (que ce soit par classes ou par prototypes),
- communication par messages,
- polymorphisme,
- héritage (sous-typage ou classification, etc.),
- tout est objet.

Maintenant, ce que j'attends en plus d'un langage objet est aussi:
- conception par contrat (pré/post conditions + invariants),
- si typage statique, la covariance multiple et la généricité contrainte,
- les closures,
- et, si en plus le langage supporte la syntaxe language (sujet verbe
complément) comme avec SmallTalk ou Lisaac, alors je suis heureux :)

A côté de ceci, sauf erreur de ma part, tu sembles faire la distinction
entre langage objet et langage orienté objet.
Je voudrais faire remarqué ceci: chez les anglais, lorsqu'ils désignent un
langage qui supporte des caractéristiques d'un paradigme de programmation,
ils le désignent par le mot "oriented", comme par exemple pour le paradigme
objet, object-oriented language ou, pour la programmation par aspect,
aspect-oriented programmation. Ceci a donné en français "langage orienté
objet" (on aime bien traduire mot par mot les expressions anglo-saxones :))
mais la dénomination "langage objet" en français existe aussi. Ceci a
conduit a donner une distinction entre les deux. Il n'y en a pas. Ça n'a
rien à voir avec le fait qu'un langage soit "plus" objet qu'une autre comme
certains le disent plaisamment. AMHA, la vrai dénomination, plus française
si jamais ça existe, devrait être "langage par objets".

Post by Miguel Moquillon
Mais peut-être qu'à la lecture de l'article sur JavaScript, je changerais
mon opinion sur celui-ci.

peut-etre mais apparement tu as deja des idées tres arretés sur JavaScript

C'est vrai, je l'admet. Mais mes idées arrivent à changer, à plus ou moins
long terme selon si elles sont bien ou peu arrêtées

Laurent Deniau

2006-01-09 11:19:06 UTC

Post by zwetan
quel est pour toi un langage vraiment objet ?

Il me semble pourtant l'avoir écrit.
Un langage objet est un langage qui supporte les caractéristiques centrales
- encapsulation,
- typage (Liskov ou Cook), qu'il soit statique, dynamique ou par inférence,
- définition d'objets (que ce soit par classes ou par prototypes),
- communication par messages,
- polymorphisme,
- héritage (sous-typage ou classification, etc.),
- tout est objet.

D'apres ces definitions, C est aussi un langage objet.

Post by Miguel Moquillon
- conception par contrat (pré/post conditions + invariants),
- si typage statique, la covariance multiple et la généricité contrainte,
- les closures,
- et, si en plus le langage supporte la syntaxe language (sujet verbe
complément) comme avec SmallTalk ou Lisaac, alors je suis heureux :)

Tout ca aussi, C permet de le faire.

Donc peut-etre il faudrait ajouter supporte 'nativement'?

a+, ld.

Miguel Moquillon

2006-01-09 12:51:14 UTC

Post by Miguel Moquillon
Un langage objet est un langage qui supporte les caractéristiques
- encapsulation,
- typage (Liskov ou Cook), qu'il soit statique, dynamique ou par
inférence, - définition d'objets (que ce soit par classes ou par
prototypes), - communication par messages,
- polymorphisme,
- héritage (sous-typage ou classification, etc.),
- tout est objet.

D'apres ces definitions, C est aussi un langage objet.

C supporte t'il par exemple le polymorphisme ? Non. Il faut l'implémenter
soit même.
Quand j'écris "supporte", cela signifie de façon native. Sinon, j'aurais
écris plutôt "permette d'obtenir/d'implémenter"

Tout ca aussi, C permet de le faire.

Avoir la caractéristique syntaxique langage dans C, ça ne doit pas être du
coton. Idem avec la conception par contrat.

Post by Laurent Deniau
Donc peut-etre il faudrait ajouter supporte 'nativement'?

AMHA C'est redondant. En fait le verbe "supporter" signifie bien que le
langage _a_ ses caractéristiques, et non permet de les avoir.

Post by Laurent Deniau
a+, ld.

Laurent Deniau

2006-01-09 14:16:49 UTC

D'apres ces definitions, C est aussi un langage objet.

C supporte t'il par exemple le polymorphisme ? Non. Il faut l'implémenter
soit même.

Si (je precise polymorphisme de soustypage pour le cas present).

C supporte nativement le polymosphisme de soustypage au sens de Liskov.
Ce qu'il faut pour faire ce polymorphisme, c'est (implicitement ou
explicitement) la notion de pointeur et la possibilite de reinterpreter
une aggregation sur une 'sous-aggregation', c'est-a-dire etre autorise
par le langage a appliquer le principe de substitution. Et la norme du C
l'autorise.

Ce que C ne supporte pas, c'est la variance de type que "presque" tous
les langages OO supportent (certains ont un typage fort sans proposer de
regle de variance de type). Et la il faut le faire a la main avec un cast.

Accessoirement, la variance de type n'a de sens que sur un systeme de
typage fort, ce que C supporte aussi nativement.

Post by Miguel Moquillon
Quand j'écris "supporte", cela signifie de façon native. Sinon, j'aurais
écris plutôt "permette d'obtenir/d'implémenter"

Suivant le concept OO dont on parle, la difference peut-etre subtile
voila pourquoi je precisais ;-) Par exemple, C++ a etendu
considerablement ces capacites OO grace a la combinaison
macros+templates parce qu'ils permettent d'obtenir ces concepts.

Tout ca aussi, C permet de le faire.

Avoir la caractéristique syntaxique langage dans C, ça ne doit pas être du
coton. Idem avec la conception par contrat.

- conception par contrat, c'est plus une discipline de programmation
qu'un probleme de support syntaxique.

- typage statique, covariance simple et genericite contrainte demande de
passer par des macros. La covariance multiple ne me semble pas
accessible au C, mais peut-etre que qqun a trouve comment le faire.

- closures, c'est essentiellement un probleme de gestion memoire qui se
resout par un comptage de reference sur objet dynamique.

Post by Laurent Deniau
Donc peut-etre il faudrait ajouter supporte 'nativement'?

AMHA C'est redondant. En fait le verbe "supporter" signifie bien que le
langage _a_ ses caractéristiques, et non permet de les avoir.

Sur le fond, je suis biensur d'accord ;-)

a+, ld.

Miguel Moquillon

2006-01-09 15:33:11 UTC

Post by Laurent Deniau
C supporte nativement le polymosphisme de soustypage au sens de Liskov.
Ce qu'il faut pour faire ce polymorphisme, c'est (implicitement ou
explicitement) la notion de pointeur et la possibilite de reinterpreter
une aggregation sur une 'sous-aggregation', c'est-a-dire etre autorise
par le langage a appliquer le principe de substitution. Et la norme du C
l'autorise.

Tu le peux effectivement si tu écris toi même le mécanismes le permettant :
c'est à dire écrire une relation entre des structures de données qui
permettent ceci (le plus simple : champs communs entre les deux structures
de données "parentes"). Ce n'est pas fournit par défaut par un mécanisme du
langage, tu utilises juste les possibilités du langage pour implémenter ou
simuler un tel mécanisme.

Post by Laurent Deniau
- conception par contrat, c'est plus une discipline de programmation
qu'un probleme de support syntaxique.

Je ne suis pas tout à fait d'accord là dessus. La conception par contrat est
avant tout un support à la fois syntaxique mais aussi sémantique. Par
exemple, le support de la conception par contrat (qui est autre chose que
de simples assertions) permet de penser différemment la gestion des
exceptions puisque ces dernières ne sont plus alors gérées de la façon
"classique" : en gros les exceptions sont provoquées par des violations de
contrat, à partir de là, on pense les exceptions différemment.

Post by Laurent Deniau
- closures, c'est essentiellement un probleme de gestion memoire qui se
resout par un comptage de reference sur objet dynamique.

Je ne crois pas car lorsque tu passes d'un appel à un autre, entre temps ton
compteur de référence peut-être à 0 et là bye bye. Une implémentation
classique des closures est la gestion d'une structure de données qui
contient un pointeur sur le code de la fonction et l'ensemble des
variables/valeurs de la fonction crée au moment de son appel. En C, on peut
simuler les closures en utilisant le mot-clé static. Par exemple:
int myfunc()
{
static int call_count = 0;
static struct FuncState_t state_info;
return ++call_count;
}

Laurent Deniau

2006-01-09 16:54:58 UTC

c'est à dire écrire une relation entre des structures de données qui
permettent ceci (le plus simple : champs communs entre les deux structures
de données "parentes"). Ce n'est pas fournit par défaut par un mécanisme du
langage, tu utilises juste les possibilités du langage pour implémenter ou
simuler un tel mécanisme.

Cette relation de *polymorphisme* est necessaire meme dans les langages
OO, ce n'est donc pas un critere.

C:
struct Derived { struct Base; ... };

C++:
struct Derived : Base { ... };

En revanche la relation de C++ est plus riche, elle integre egalement
l'heritage qui inclu une regle pour la variance du type derive.

Application au polymorphisme:

typedef struct Base {
char *name;
} *Base;

typedef struct Derived {
struct Base Base;
int val;
} *Derived;

void print(Base base) // polymorphique
{
printf(base->name);
}

int main(void)
{
struct Base base[1] = {{ "Base" }};
struct Derived derived[1] = {{{ "Derived" }, 10 }};

print(base);
print((Base)derived); // non support de type variant -> cast
}

Ce que C ne supporte pas, c'est une regle pour autoriser la variance des
type selon les regles de l'heritage et oblige a utiliser un cast. Cela
parait evident puisque le C n'integre pas de notion d'heritage,
seulement de polymorphisme (au moins deux cas dans la norme: le
recouvrement d'aggregation a l'offset zero et les flexibles arrays). Les
extension de gcc offre d'avantage de cas de polymorphismes.

Si par exemple on va plus loin (cas de OOC) et que toutes les methodes
de classes sont virtuelles et que la definition d'une classe utilise
quelques macros, alors le cast n'est plus utile. On est dans le cas que
tu dis, un support 'non-natif' de la variance de type.

Post by Laurent Deniau
- conception par contrat, c'est plus une discipline de programmation
qu'un probleme de support syntaxique.

J'ai lu le Meyer, mais je n'ai pas assez d'experience dans l'utilisation
de la programmation par contrat. Je suis cependant tout a fait d'accord
que ce ne sont pas de simples assertions mais plutot des ensembles
d'assertions (au sens mathematique du terme) avec les notions de
commutativite et de distributivite qui vont avec.

Qu'est ce que tu entends par "on pense les exceptions différemment".

Post by Laurent Deniau
- closures, c'est essentiellement un probleme de gestion memoire qui se
resout par un comptage de reference sur objet dynamique.

Je ne crois pas car lorsque tu passes d'un appel à un autre, entre temps ton
compteur de référence peut-être à 0 et là bye bye. Une implémentation

Je me suis mal exprime:

1) si les objects sont alloues sur le tas (ou statiques/globaux mais pas
automatiques), c'est ce que j'entendais par dynamique.
2) si chaque objet supporte le comptage de reference (ou le langage
utilise un GC)

et si le langage supporte les aggregation et les pointeurs de fonction
(comme le C) alors les closures sont triviales a implementer. Et
effectivement dans le cas non-GC, elles incrementent le compteur de
reference des objets qu'elles referencent pour prolonger leur duree de
vie au dela du contexte lexical courant.

1) est lies a une politique systematique de la gestion de la memoire des
objets
2) est lies a une politique systematique de la gestion de la duree de
vie des objets qui dans le cas du GC releve uniquement de la gestion
memoire.

Deux concepts present dans beaucoup de langage OO, et tout a fait
implementable en C (et present dans OOC), c'est ce que j'ai voulu dire.

Post by Miguel Moquillon
classique des closures est la gestion d'une structure de données qui
contient un pointeur sur le code de la fonction et l'ensemble des
variables/valeurs de la fonction crée au moment de son appel. En C, on peut
simuler les closures en utilisant le mot-clé static.

C'est seulement un cas particulier non reentrant d'implementation donc
non recommande.

a+, ld.

Miguel Moquillon

2006-01-10 09:16:17 UTC

Post by Laurent Deniau
Cette relation de *polymorphisme* est necessaire meme dans les langages
OO, ce n'est donc pas un critere.

Je ne comprends pas ce que tu veux dire ici.

Post by Laurent Deniau
struct Derived { struct Base; ... };
[ ... ]

Oui, en écrivant d'une certaine façon les structures de données, tu peux
effectivement implémenter une forme d'héritage et par là pouvoir simuler le
polymorphisme. Si tu veux rendre transparent ceci, tu as à écrire un
framework qui implémente les mécanismes objet pour C (cf. GTK+ avec GObject
par exemple). Ce qui est différent d'un "langage qui supporte nativement"
pour reprendre ton expression :).

Je ne parle évidemment pas de C++ ou d'ObjC qui eux supportent les concepts
objets d'héritage, de délégation (pour ObjC) et de polymorphisme.

Post by Laurent Deniau
seulement de polymorphisme (au moins deux cas dans la norme: le
recouvrement d'aggregation a l'offset zero et les flexibles arrays).

?. Je n'appelle pas ça du polymorphisme. A la rigueur une ressemblance ou
simulation de ce dernier.

Post by Laurent Deniau
Qu'est ce que tu entends par "on pense les exceptions différemment".

Dans les langages objet de masse (C++, Java, etc.), et dans d'autres, les
exceptions sont des classes d'objets à définir et à lever explicitement.
Dans Java, on doit en plus spécifier dans la signature des méthodes les
exceptions qui peuvent intervenir.
En Eiffel, les exceptions ne sont que des "signaux" issus d'une violation de
contrat (bien que l'on peut en lever un explicitement). Donc, lorsque tu
écris une classe d'objets, tu penses tes cas exceptionnels (ce que devrait
être une exception) en termes de contrats. Par exemple, dans le cas d'une
ouverture de fichier (exemple très simplifié):
class FILE
...
feature
open(filename: STRING)
require
filename /= Void and not filename.is_empty
do
...
ensure
is_open
end
end

Si l'ouverture de fichier échoue, is_open est toutjours à false et donc une
exception est levée par le runtime parce que la post-condition (le contrat
de la routine à la fin de son exécution) n'est pas respectée.

Post by Laurent Deniau
- closures, c'est essentiellement un probleme de gestion memoire qui se
resout par un comptage de reference sur objet dynamique.

Je ne crois pas car lorsque tu passes d'un appel à un autre, entre temps
ton compteur de référence peut-être à 0 et là bye bye. Une implémentation

1) si les objects sont alloues sur le tas (ou statiques/globaux mais pas
automatiques), c'est ce que j'entendais par dynamique.
2) si chaque objet supporte le comptage de reference (ou le langage
utilise un GC)

Ok.

Mais faut pas se leurrer. Simuler un mécanisme ou un principe ne veut pas
dire le supporter (supporter nativement comme tu dis :) ). Car, en effet,
ceci reste de la simulation, ou une implémentation explicite et souvent
limitée d'un mécanisme en utilisant les propriétés du langage
(polymorphisme et closure pour ne citer que ces deux avec le C).

Laurent Deniau

2006-01-10 10:19:10 UTC

Post by Laurent Deniau
Cette relation de *polymorphisme* est necessaire meme dans les langages
OO, ce n'est donc pas un critere.

Je ne comprends pas ce que tu veux dire ici.

Je veux pointer du doigt la difference entre (1)polymorphisme,
(2)subtyping et (3)heritage.

(1) et (2) sont semantiquement disjoints mais se recouvre en pratique.

(3) inclus (1)+(2), mais (1)+(2) ne donne pas (3)

Le C supporte (1) et (2) au sens de Liskov mais pas (3). (cf plus bas).
Quand je dis supporte, c'est qu'il y a tous les ingredients dans la
norme pour etre autorise a le faire officiellement.

Post by Laurent Deniau
struct Derived { struct Base; ... };
[ ... ]

Ce n'est pas une simulation, c'est cette facon d'utiliser les
aggregations qui est prevue par la norme.

Post by Miguel Moquillon
framework qui implémente les mécanismes objet pour C (cf. GTK+ avec GObject
par exemple).

Je ne suis pas pret d'utiliser GObject beaucoup trop lourd et avec tres
peu de check a la compilation. OOC (Object Oriented C, completement C89)
est beaucoup plus simple, beaucoup plus evolue et fournit beaucoup de
checks a la compilation. OOC est inspire de Java, C# et C++. Je suis
aussi depuis une semaine entrain de travailler sur COS (C Object System,
completement C89) qui lui est inspire d'Objective-C et de CLOS et est
encore plus simple, plus flexible et plus dynamique que OOC. Les deux
valent (voir surpasse ;-) ) pas mal de langages OO tres connus.

Post by Miguel Moquillon
Ce qui est différent d'un "langage qui supporte nativement"
pour reprendre ton expression :).

Pour l'heritage et les autres concepts OO je suis entierement d'accord.
Pour le polymorphisme, c'est natif en C, precise dans la norme et
utilisable sans artifice, code, macros ou bidouille. Je crois que je
l'ai deja dit ;-) et c'etait ce que je voulais souligner. Sans les
precisions utiles dans la norme, ca devient une bidouille plus ou moins
portable, et c'est toute la difference avec un 'support' par le langage
comme tu le soulignes.

Note que si le cast te gene, print peut etre reecrit pour l'eviter:

void print(void *base) // polymorphique
{
Base b = base;
printf(b->name);
}

avec dans le main:

print(base);
print(derived);

Tout ca est tout a fait valide meme si ce n'est pas recommande ;-)

Post by Miguel Moquillon
Je ne parle évidemment pas de C++ ou d'ObjC qui eux supportent les concepts
objets d'héritage, de délégation (pour ObjC) et de polymorphisme.

Post by Laurent Deniau
seulement de polymorphisme (au moins deux cas dans la norme: le
recouvrement d'aggregation a l'offset zero et les flexibles arrays).

?. Je n'appelle pas ça du polymorphisme. A la rigueur une ressemblance ou
simulation de ce dernier.

Pourtant c'est bien du polymorphisme au sens de Liskov:

Barbara Liskov, “Data Abstraction and Hierarchy,”
SIGPLAN Notices,
23,5 (May, 1988).

"What is wanted here is something like the following substitution
property: If for each object o1 of type S there is an object o2
of type T such that for all programs P defined in terms of T, the
behavior of P is unchanged when o1 is substituted for o2 then S is a
subtype of T."

L'exemple ci-dessus de print le montre avec

o1 = derived de type S = Derived
o2 = base de type T = Base
P = print

Le programme print reste inchange et valide, on a donc bien (1) et (2).

De plus si on prend C++ pour lequel je suppose que tu admets qu'il
supporte le polymorphisme, on peut ecrire le code suivant semantiquement
equivalent a l'exemple ci-dessus:

Base::print()
{
printf(name);
}

et dans le main:

base.print();
derived.print();

Note que le "type checking" et le "method overriding" ne sont pas aborde
dans mes propos.

Post by Laurent Deniau
Qu'est ce que tu entends par "on pense les exceptions différemment".

Ce que tu veux dire, c'est qu'en fait tu ne pense plus aux exceptions,
mais aux contrats et tu laisses le systeme s'occuper de transcrire la
violation de ces derniers en terme d'exceptions.

a+, ld.

Miguel Moquillon

2006-01-10 13:21:44 UTC

Post by Laurent Deniau
OOC (Object Oriented C, completement C89)
est beaucoup plus simple, beaucoup plus evolue et fournit beaucoup de
checks a la compilation. OOC est inspire de Java, C# et C++.

Je ne connais pas OOC.

Post by Laurent Deniau
Je suis
aussi depuis une semaine entrain de travailler sur COS (C Object System,
completement C89) qui lui est inspire d'Objective-C et de CLOS et est
encore plus simple, plus flexible et plus dynamique que OOC. Les deux
valent (voir surpasse ;-) ) pas mal de langages OO tres connus.

Là, tu m'intéresse au plus haut point ;) As tu des liens dessus ?

Miguel

Laurent Deniau

2006-01-10 15:56:06 UTC

Post by Laurent Deniau
OOC (Object Oriented C, completement C89)
est beaucoup plus simple, beaucoup plus evolue et fournit beaucoup de
checks a la compilation. OOC est inspire de Java, C# et C++.

Je ne connais pas OOC.

Là, tu m'intéresse au plus haut point ;) As tu des liens dessus ?

Non pas encore. En fait je profitais des vacances pour commencer a
documenter OOC en vu d'une mise sur le web. Au cours de l'ecriture du
manuel, j'ai trouve que OOC avait finalement beaucoup (trop?) de
concepts (alors que je le voulais simple) et que le manuel qui devait
faire 30 pages allait plutot vers les 150p - tres demoralisant. En
parallele, j'ai lu le livre de Sonya Keene sur CLOS et on m'a mentionne
l'existance de Dynace qui utilise un preprocesseur specifique (dpp) et
ne supporte pas les multimethodes.

Avec l'experience de OOC et ce que je connaissais de CLOS et
d'Objective-C, il n'a pas ete difficile de faire qques macros pour faire
COS (defclass, defgeneric, defmethod), et je suis toujours dessus
probablement encore pour qques semaines. Je finalise ce soir le package
de macros pour manipuler des listes a la compilation.

Ce qui me seduit dans cette approche, c'est la programmation par verbes
(generiques) au lieu de noms (classes), ces derniers etant generalement
beaucoup plus nombreux. En fait, ce ne sont plus les classes (qui ont
tres peu de couplage entre elles) qui dominent le design, mais
d'avantage les methodes que l'on veut leur ajouter (ce qui peut etre
fait independament de la classe). Le couplage existe mais au niveau des
generiques (defgeneric). C'est la que le design est important, mais
normalement ca devrait etre plus simple que le design OO classique
puisqu'on pense naturellement en terme de comportement (verbe). De plus
la facon de l'utiliser est beaucoup naturelle pour ceux qui viennent du
C puisque les generiques se manipulent comme des fonctions (ex: object
gAdd(object, object)). Bon, mais il faut que j'avance si je veux que ca
marche un jour ;-)

a+, ld.

Miguel Moquillon

2006-01-10 17:05:03 UTC

Post by Laurent Deniau
Ce qui me seduit dans cette approche, c'est la programmation par verbes
(generiques) au lieu de noms (classes), ces derniers etant generalement
beaucoup plus nombreux. En fait, ce ne sont plus les classes (qui ont
tres peu de couplage entre elles) qui dominent le design, mais
d'avantage les methodes que l'on veut leur ajouter (ce qui peut etre
fait independament de la classe). Le couplage existe mais au niveau des
generiques (defgeneric). C'est la que le design est important, mais
normalement ca devrait etre plus simple que le design OO classique
puisqu'on pense naturellement en terme de comportement (verbe). De plus
la facon de l'utiliser est beaucoup naturelle pour ceux qui viennent du
C puisque les generiques se manipulent comme des fonctions (ex: object
gAdd(object, object)). Bon, mais il faut que j'avance si je veux que ca
marche un jour ;-)

Et peut-on aussi sortir de la syntaxe function(arg1, arg2) et avoir, dans
l'esprit un peu plus objet, plutôt le modèle langage.
Exemple dans ObjC ou Smalltalk:
myarray at: 3 add: myobject
ou encore dans lisaac:
myarray.add myobject at 3

mais peut-être ce n'est pas conforme à l'approche verbe.

Miguel

Laurent Deniau

2006-01-10 17:27:58 UTC

Et peut-on aussi sortir de la syntaxe function(arg1, arg2) et avoir, dans
l'esprit un peu plus objet, plutôt le modèle langage.

Attention, ce n'est pas function(arg1, arg2) mais function(obj1, obj2)!
La methode invoquee depende de obj1 *et* obj2. Une multi-methode donc.
C++, C#, Java, Objective-C, etc... ne supportent pas les multi-methodes.

Post by Miguel Moquillon
myarray at: 3 add: myobject
myarray.add myobject at 3
mais peut-être ce n'est pas conforme à l'approche verbe.

Effectivement, ce n'est pas "conforme" a l'approche verbe et de plus
cela oblige a avoir une syntaxe differente pour les methodes et les
multi-methodes. Quelle extension de syntaxe utiliserais-tu pour un appel
de multi-methode en Objective-C ou en C++? Je prefere une approche
uniforme, simple et proche du C de surcroit. Meme si un *utilisateur*
venant du C ne sait pas ce qu'est un generic, un override ou une
multi-methode, il peut quand meme l'utiliser en faisant le parallele
avec generic = prototype et methode = fonction et faire abstraction des
mechanismes de classes et de resolutions de methodes, le reste (la
partie OO) pourrait "presque" etre considere comme secondaire. C'est en
ce sens que je pense que COS sera beaucoup plus simple a expliquer que
OOC (tres proche de Java).

a+, ld.

Miguel Moquillon

2006-01-11 09:25:23 UTC

Post by Laurent Deniau
Attention, ce n'est pas function(arg1, arg2) mais function(obj1, obj2)!
La methode invoquee depende de obj1 *et* obj2. Une multi-methode donc.
...
Quelle extension de syntaxe utiliserais-tu pour un appel
de multi-methode en Objective-C ou en C++?

Je n'aime pas cette expression de multi-méthode parce qu'elle amène à penser
d'une certaine façon cette caractéristique. Je lui préfère le terme anglais
multi-dispatching qui est plus ouvert.
Le langage Slate, qui est un langage objet à prototype basé sur la syntaxe
Smalltalk, et donc sur le modèle langage, implémente cette caractéristique.
Le site de Slate: http://slate.tunes.org/
Deux papiers sur le multi-dispatching écris par les concepteurs de Slate:
- Prototype With Multiple Dispatch: http://tunes.org/~eihrul/pmd.pdf
- Prototypes With Multiple Dispatch: An Expressive and Dynamic Object Model:
http://tunes.org/~eihrul/ecoop.pdf

C'est très intéressant et ceci peut, peut-être, te donner quelques idées.

Miguel

Laurent Deniau

2006-01-11 10:34:18 UTC

Je n'aime pas cette expression de multi-méthode parce qu'elle amène à penser
d'une certaine façon cette caractéristique. Je lui préfère le terme anglais
multi-dispatching qui est plus ouvert.

C'est deux choses differentes a mon sens. Multi-methode implique que la
methode est specialisee pour plusieurs classes a la fois. Le
multi-dispatching est le mechanisme pour trouver de telles
multi-methodes et il y a plusieurs techniques pour le faire. Apparament
les papiers que tu me cites ci-dessous on le meme vocabulaire et utilise
multi-methode dispatch (cf 2.1) qu'il abbrege par la suite en
multi-dispatch.

Post by Miguel Moquillon
Le langage Slate, qui est un langage objet à prototype basé sur la syntaxe
Smalltalk, et donc sur le modèle langage, implémente cette caractéristique.
Le site de Slate: http://slate.tunes.org/
- Prototype With Multiple Dispatch: http://tunes.org/~eihrul/pmd.pdf
http://tunes.org/~eihrul/ecoop.pdf

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, d'ou la possibilite
d'une syntaxe lie a l'instance (comme en C++ ou Java) mais aussi la
difficulte d'ajouter des methodes a une classe incomplete. En COS (comme
en CLOS ou Dylan), des methodes peuvent etre ajoute a volonte et ce
n'importe ou. Si ces methodes accedent aux champs des instances, elles
ont besoin de la definition de la classe, sinon ce n'est pas utile.
C'est un des aspects fort de l'ADT des classes. En COS ca donne (en C99):

** generic.h // prototypes

[...]
defgeneric (object, gPrint);
defgeneric (object, gMoveToXY, int, int);
defgeneric2(int , gEqual); // multi-methode d'ordre 2

** generic.c // objets associes aux prototypes

[...]
makgeneric (object, gPrint);
makgeneric (object, gMoveToXY, int, int);
makgeneric2(int , gEqual);

** Point.h // definition de classe

#include <cos/object.h>

defclass(Point)
int x,y;
endclass

** Point.c // objets associes a la classe + qques methodes

#include <stdio.h>
#include "generic.h" // generic coupling (verbs)
#include "Point.h" // class coupling (nouns)

makclass(Point);

defmethod(object, gPrint, Point)
printf("(%d,%d)\n", Self->x, Self->y);
return self;
endmethod

defmethod(object, gMoveToXY, Point, int x, int y)
Self->x += x, Self->y += y;
return self;
endmethod

** Point_extend.c

#include "Point.h"
#include "generic.h"

defmethod2(int, gEqual, Point, Point)
return Self1->x == Self2->x && Self1->y == Self2->y
endmethod

** main.c
#include "generic.h"

useclass(Point); // weak class coupling

int main(void) {
object pt = gNew(Point);
object pt2;
gMoveToXY(pt, 10, 12);
gPrint(pt);
pt2 = gClone(pt);
gPrint(pt2);
printf("pt == pt2: %d\n", gEqual(pt, pt2));
gDelete(pt);
gDelete(pt2);
}

Post by Miguel Moquillon
C'est très intéressant et ceci peut, peut-être, te donner quelques idées.

Peut-etre je vais regarder en details tout ca, mais les choses sont deja
tres clair dans ma tete. Et cote syntaxe, les macros du C ne peuvent pas
faire des miracles (quoique). Si

obj = gAdd(obj1,obj2);

ne convient pas, je dois passer par une macro pour en changer la
syntaxe, parce que gAdd est en fait un prototype qui definit le generic
(prototype + fonction inline + objet instance de Generic[Multi]Method)
et en C il n'y a pas plusieurs facon de declarer un prototype. De plus
en C89, cela veut dire que qqpart le nombre d'argument est specifie. Par
exemple en OOC j'ai

call (obj, copy, obj2); // C99
call1(obj, copy, obj2); /* C89, le 1 precise la presence d'obj2 */

Avec l'experience, ce n'est pas du tout un probleme et devient
rapidement naturel.

Qui plus est cette macro evalue deux fois obj sauf si on compile avec gcc.

call(obj, print); // equivalent a obj->_isa->print(obj);

Pour evite cet effet de bord invisible, call impose a obj d'etre une
lvalue ce qui empeche a obj d'etre un appel de fonction. Le contre coup
c'est qu'on ne peut pas chainer syntaxiquement les appels vituels.

call(call(obj, mth1), mth2); // ne compile qu'avec gcc

a+, ld.

Miguel Moquillon

2006-01-11 13:19:41 UTC

Post by Laurent Deniau
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 :)
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. On
peut considérer que les traits sont l'équivalent, dans une certaine mesure,
aux fonctions génériques.

Sinon, tes exemples sont intéressants. Toutefois j'aurais une question:
pourquoi faire par une surcouche à C ce qui existe déjà avec CLOS ?
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 ?

Miguel

Laurent Deniau

2006-01-11 14:01:24 UTC

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 ;-)

Post by Miguel Moquillon
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.

Post by Miguel Moquillon
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).

Post by Miguel Moquillon
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.

Post by Miguel Moquillon
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.

zwetan

2006-01-09 23:19:12 UTC

Post by Miguel Moquillon
Il me semble pourtant l'avoir écrit.
Un langage objet est un langage qui supporte les caractéristiques centrales
- encapsulation,
- typage (Liskov ou Cook), qu'il soit statique, dynamique ou par inférence,
- définition d'objets (que ce soit par classes ou par prototypes),
- communication par messages,
- polymorphisme,
- héritage (sous-typage ou classification, etc.),
- tout est objet.

JavaScript supporte tout ca :)

et attention sans avoir besoin de faire de gymnastique particulière,
il suffit juste de bien connaitre le langage.

pour le typage par exemple

souvent j'entends dire que JavaScript n'a pas de type,
alors que si si, il a bien des types

sauf qu'au contraire d'un langage basé sur les classes
qui aurait un typage statique et fort

JavaScript a un typage dynamique et faible
cad que n'importe quelle valeur de n'importe quel type peut etre assignée
à n'importe quelle variable et ce sans restriction,
mais en soit la variable a bien un type

je conseille fortement ces differents articles par Eric Lippert
sur le systeme de typage de JScript mis en relation avec JScript.NET
http://blogs.msdn.com/ericlippert/archive/2003/11/05/53336.aspx
http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx
http://blogs.msdn.com/ericlippert/archive/2003/11/06/53367.aspx
http://blogs.msdn.com/ericlippert/archive/2003/11/10/53376.aspx
http://blogs.msdn.com/ericlippert/archive/2003/11/12/53377.aspx
http://blogs.msdn.com/ericlippert/archive/2003/11/14/53383.aspx
http://blogs.msdn.com/ericlippert/archive/2003/11/21/53399.aspx

et d'ailleurs tous les autres articles aussi :)

pour continuer juste sur le typage

la prochaine evolution du langage: ECMAScript 4
prevoit des annotation de type, mais surtout
permettra de verifier le type pendant l'execution du code
en plus d'une verification classique a la compilation (comme le typage
statique)

et on peut voir ici
http://weblogs.mozillazine.org/roadmap/archives/009255.html#comments

comment cette evolution des types est prevue

et vraiment sans vouloir mettre une grosse tape sur la tete
aux langages basés sur les classes (pas tous...), mais perso je prefere
de loin ce systeme de typage que celui "classiquement" utilisé
qui force bien souvent a faire du casting, downcasting, upcasting etc..
juste pour avoir le bon type afin que le compilo accepte de compiler.

je comprends, mais personnellement j'ai une autre "preference"

Au lieu de la "conception par contrat" je prefere la conception dirigée
par les tests (Test Driven Development), les tests sont en quelque sorte
les "contrats" a respecter.

Quand on combine cela avec un langage dynamique qui travaille
au plus proche des objets (cad pas de metaclass, pas besoin de recompiler
pour avoir un type et/ou soustype legerement ou ompletement different),
je trouve ca tres puissant.

j'aime aussi pouvoir utiliser des fonctions comme des objets
http://w3future.com/html/stories/hop.xml

ou utiliser des fonctions de continuation plutot que des fonctions
reccursives
http://blogs.msdn.com/ericlippert/archive/2005/08/08/442706.aspx

aussi bien que les closures, les fonctions lambda etc.

mais LE truc qui me plait le plus avec JavaScript
c'est de pouvoir modifier les objets build-ins du langage
ceci combiné avecdu polymorphisme permet de faire
énormément de choses facilement

si tu veux un petit exemple observe les implementations
de la methode toSource dans un de mes projets
http://live.burrrn.com/browser/ECMA-262/core2/branches/core2_v1.0.x/src/buRRRn/core2

toSource n'existe pas dans le langage par defaut
mais a partir du moment où on l'implémente
sur les objets de base, on peut utiliser la methode
dans n'importe quel autre objet, et ce grace au polymorphisme
justement.

bon ce n'est qu'un exemple, et peut-etre meme mauvais,
mais juste pour dire que cette "manière" de faire peut rarement
s'appliquer dans des langages basés sur les classes qui ont le
plus souvent leurs objets de base defini comme abstrait.

Post by Miguel Moquillon
A côté de ceci, sauf erreur de ma part, tu sembles faire la distinction
entre langage objet et langage orienté objet.

[snip]

Post by Miguel Moquillon
certains le disent plaisamment. AMHA, la vrai dénomination, plus française
si jamais ça existe, devrait être "langage par objets".

on est d'accord donc, je pensais que toi tu faisais une différence :)

Post by Miguel Moquillon
C'est vrai, je l'admet. Mais mes idées arrivent à changer, à plus ou moins
long terme selon si elles sont bien ou peu arrêtées

comme tout le monde, y compris moi-meme :)

zwetan

Miguel Moquillon

2006-01-10 08:49:56 UTC

Tout cela me semble fort intéressant. Je n'avais jamais vue et utilisé
JavaScript de cette façon.
Toutefois, je remarque que tu parles avant tout d'ECMAScript, le JavaScript
standardisé par l'ECMA. Or, actuellement, à ma connaissance, quasi aucun
navigateur n'implémente cette version de JavaScript mais plutôt leur propre
version (dans leur petite guegerre de navigateur Web) ; ce qui nous oblige
à n'utiliser qu'un ensemble commun, et donc limité, à toutes ces versions
de JavaScript.

Miguel

zwetan

2006-01-13 12:49:04 UTC

Post by Miguel Moquillon
Tout cela me semble fort intéressant. Je n'avais jamais vue et utilisé
JavaScript de cette façon.

merci :)

Post by Miguel Moquillon
Toutefois, je remarque que tu parles avant tout d'ECMAScript, le JavaScript
standardisé par l'ECMA. Or, actuellement, à ma connaissance, quasi aucun
navigateur n'implémente cette version de JavaScript mais plutôt leur propre
version (dans leur petite guegerre de navigateur Web) ; ce qui nous oblige
à n'utiliser qu'un ensemble commun, et donc limité, à toutes ces versions
de JavaScript.

humm disons que maintenant si si les principaux navigateurs
respectent a peu pres tous ECMA-262 3eme edition
et si il y a des petits oublis ils sont assez facilement patchable

voir ce petit article (en anglais) qui parle de strategie de test pour les
navigateurs
http://www.zwetan.com/blog/buRRRn/Testing_strategy_for_browsers.html

il y avait vraiment une gueguerre a l'epoque de Netscape 4.x vs Internet
Explorer 4.x
mais si on vise principalement les navigateurs de 5eme generation
( IE 5.0 / IE 6.0, Firefox / Mozilla, Opera, Safari, Konqueror, etc.)
on reste quand meme dans un environnement assez stable
ou du moins qu'on peut stabiliser (cf la lib core2).

reste que c'est vrai cela reste compliqué de programmer
et de tester pour tous ces navigateurs,
d'un autre coté si on le fait avec soin cela permet d'avoir des
applications web, et donc des applis multi-plateforme
ce qui plutot interessant amha.

zwetan

Laurent Deniau

2006-01-09 11:31:55 UTC

Post by zwetan
ces articles disent principalement que etre basé sur les prototypes
permet autant sinon plus que etre basé sur les classes

C'est exact. On trouve d'autre article plus complet sur le site de Sun a
la rubrique Self.

Post by zwetan
et meme si il existe plusieurs formes de prototypage (avec ou sans traits
par exemple)
reste que le fait d'etre basé sur les prototypes, meme dans la plus basique
des definitions,
permet de faire de l'orienté objet.

Yep. Le probleme, c'est que l'experience a montre que cette flexibilite
depasse les besoins courants alors qu'elle ajoute un niveau de
complexite problematique pour la gestion de gros projets. Alors
rapidement on se refait un systeme a base de objet-classe avec des
prototypes. Il y a pratiquement plus d'articles sur comment faire du
objet-classe dans un langage a prototype que d'article sur les langages
a prototypes eux-memes (qui ne sont deja pas nombreux, le seul que j'ai
attentivement regarde etant Self).

Post by zwetan
apres on en revient au meme probleme: etre un langage qui permet de faire de
l'orienté objet
ou etre un langage objet

Le premier point est un probleme de syntaxe. Si un langage permet de
faire de l'oriente objet mais n'est pas objet, la question est quel
prix(*) sommes-nous pret a payer pour faire de la POO dans ce langage?

(*)prix ici peut representer la quantite de code supplementaire a taper,
ou l'absence de detection d'erreur a la compilation, ou une forme non
conventionnelle de programmer, etc...

Post by zwetan
et sur ce je repette ma question
quel est pour toi un langage vraiment objet ?

Un langage qui permet de creer-manipuler-detruire des objets.
Qu'est-ce qu'un objet pour toi?

a+, ld.

zwetan

2006-01-09 23:46:34 UTC

"Laurent Deniau" wrote:
[snip]

Post by Laurent Deniau
Yep. Le probleme, c'est que l'experience a montre que cette flexibilite
depasse les besoins courants alors qu'elle ajoute un niveau de
complexite problematique pour la gestion de gros projets. Alors
rapidement on se refait un systeme a base de objet-classe avec des
prototypes. Il y a pratiquement plus d'articles sur comment faire du
objet-classe dans un langage a prototype que d'article sur les langages
a prototypes eux-memes (qui ne sont deja pas nombreux, le seul que j'ai
attentivement regarde etant Self).

le probleme avec les "besoins courants" c'est qu'on voit arriver
aussi de la "programmation courante", un peu comme ce qui est dit ici
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

Je n'ai rien contre Java, mais de plus en plus souvent
je ne vois que des gens pensant que si on fait du Java on fait de l'Orienté
Objet
et que tout le reste (qui ne ressemble pas a Java) est a jeter et/ou n'est
pas serieux.

Mais ce que tu dis est vrai, on se refait souvent un systeme a base de
objet-classe,
meme avec un langage basé sur les prototypes (moi le 1er d'ailleurs :)).

Personnellement je n'ai rien contre les classes en elle-meme,
c'est juste que je veux etre libre de pouvoir le faire avec des prototypes.

Post by Laurent Deniau
Le premier point est un probleme de syntaxe. Si un langage permet de
faire de l'oriente objet mais n'est pas objet, la question est quel
prix(*) sommes-nous pret a payer pour faire de la POO dans ce langage?
(*)prix ici peut representer la quantite de code supplementaire a taper,
ou l'absence de detection d'erreur a la compilation, ou une forme non
conventionnelle de programmer, etc...

pas faux du tout, surtout en ce qui concerne le (*)prix

mais souvent ce que je reponds (peut etre a tort)
dans le cas d'un langage comme JavaScript qui ne permet
pas de detecter des erreurs a la compilation comme pourrais
le faire un compilateur avec du typage statique

dans les 2 cas le prix de maintenance du "programme"
doit garantir (au mieux) le fait de ne pas comporter d'erreures (au
possible)

et ca on ne peut pas le garantir avec juste un compilateur qui compile
il faut des tests qui eux verifient la bonne execution du "programme"

et JavaScript peut-etre testé aussi bien que Java, meme sans typage statique
petit exemple ici:
http://www.burrrn.com/unittests/core2_v1.0.1_JS_runUnitTest.html

juste pour dire que la verification du compilateur n'est pas une fin en soi
:)

Post by Laurent Deniau
Un langage qui permet de creer-manipuler-detruire des objets.
Qu'est-ce qu'un objet pour toi?

un objet c'est la caracterisation
d'une personne, d'un endroit, d'une chose, d'une entité, d'un concept, d'un
écran, etc...

enfin en restant court :)

zwetan

Vinzoo Weber

2005-11-29 22:50:51 UTC