(snip)
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersCe qui implique pour commencer une notion de type. Quel est le type
d'un objet dans un langage à prototype ? Et même, pour commencer,
qu'est-ce qu'un type ?-)
Un type définit un ensemble de "valeurs" et d'opérations autorisées sur
ces valeurs. Les valeurs d'un objet sont en fait l'ensemble de ses états
autorisés
A tu conscience que dans un langage comme javascript, ce que tu dis n'a
aucun sens ?
var obj = {foo: 42, bar: "allo"};
quel est le "type" de cet objet selon ta définition ?
obj.foo = "whatever";
obj.yadda = function(x) { return this.foo + x; }
Et maintenant ?
Attention, tous les langages ne supportent pas la définition de types
utilisateur.
T'a vu un utilisateur ???
Post by WykaaaQui a dit que JavaScript était un langage objet?
D'abord, c'est javascript, pas "JavaScript". Ensuite, javascript permet
de créer des objets définis par une identité, un état et un
comportement, et commnuniquants par envoi de messages. Donc javascript
est un langage objet, CQFD.
Accessoirement, à part David Flanagan et toi, tout le monde s'accorde à
définir javascript comme un langage objet à prototype - et
accessoirement le seul langage à prototype universellement connu et utilisé.
Post by WykaaaQui a dit que JavaScript permettait de définir des types ?
En fonction de quelle définition du terme "type" ?
Post by WykaaaCertainement pas moi. JavaScript n'est pas un langage objet
Bin si.
Post by Wykaaa(il en a
juste certaines caractéristiques).
Il en a toutes les caractéristiques, sauf si on considère que les
messages eux même doivent être des objets, auquel cas seuls Smalltalk et
Self sont des langages objets.
Post by WykaaaJavaScript est plutôt un langage
d'acteur non objet.
A tes souhaits.
Post by WykaaaIl est donc normal que la définition de ce qu'est un type ne s'applique
pas à JavaScript qui n'est pas un langage vraiment typé.
Pour quelle définition de "type" ?
J'ai déjà vu passer toutes ces discussions sur pas mal de ng anglophones
(où il y a quand même un peu plus d'animation qu'ici), et il y a au
moins un point qui ressort clairement: il n'y a pas de définition
universellement acceptée de ce qu'est un "type" en informatique. Il y a
plusieurs théories, qui se rejoignent sur certains points et divergent
sur d'autre, certaines sont plus "mainstream" que d'autre, mais il n'y
a, je répète, aucun fondement théorique universellement accepté.
Post by WykaaaPost by Bruno DesthuilliersBref, merci pour le cours pour grand débutant... ça fait plus de 10 ans
que je programme, donc ce genre de définitions de base pour étudiant en
première année, c'est bon, je peux te les sortir moi-même.
C'est la définition d'un type, que tu le veuille ou non et ce n'est pas
une définition que tu dois traiter par le mépris car toute la
littérature sur les fondements des types sont d'accord avec cette
définition.
A tes souhaits.
Post by WykaaaJe te conseille de (re)lire "On Understanding Types, Data Abstraction,
and Polymorphism" de Luca Cardelli et Peter Wegner (Computing Survey,
Vol 17, No. 4, Décembre 1985).
(snip)
En cherchant un peu, je pourrais te sortir plusieurs articles au moins
aussi "sérieux" qui contredisent celui ci.
Autre chose ?
Post by WykaaaPost by Bruno DesthuilliersPost by Wykaaa(l'ensemble des n-uplets autorisés sur les valeurs de ses
attributs).
Dans un langage fonctionnel tel que ML, les fonctions elles-mêmes ont un
type, ce qui permet l'inférence de types.
Merci, je connais ML, et OCaml, et Haskell, et d'autres encore.
Tu les connais mais les as-tu pratiqués ?
Je n'en n'ai hélas pas eu l'occasion (j'entends par là, dans le cadre
d'un projet sérieux et non trivial), mais je te prie de me créditer
d'assez d'intelligence pour être capable de comprendre - d'après ce que
je connais de ces langages et d'autres - ce qu'est l'inférence de type
en théorie et en pratique.
Post by WykaaaJ'ai écrit un programme de 3000 lignes de ML. C'est un langage
extraordinaire (mon langage favori en fait).
J'ai écrit plusieurs programme de 15000 lignes en Python - qui en aurait
probablement nécessité plus du sextuple en Java. C'est un langage
extraordinaire (Python, je veux dire, pas Java) - mon langage favori en
fait.
Sinon, j'ai aussi écrit un programme de 75000 lignes en "W-langage" (la
parodie de langage de cette parodie d'outil de dev qu'est Windev), et
c'est vraiment un langage de MERDE. Le pire que j'ai jamais eu à subir,
j'en venais, tiens toi bien, à regretter VB. Si si, je te jure.
Autre chose ?
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by ldEt en general c'est la que les
choses se compliquent ;-)
Indeed !-)
Comme je disais, donc, c'est là que les choses se compliquent. Quand je
pose des questions comme "qu'est-ce qu'un type", c'est bien parce que je
sais qu'il n'y a *pas* UNE réponse simple et universellement applicable.
Comme dit Laurent, "c'est là que les choses se compliquent".
Non, non, il n'y a rien de compliqué sauf à vouloir faire rentrer des
langages dans l'approche objet alors qu'ils ne sont pas objet, comme
beaucoup de langages d'acteurs et JavaScript en particulier :-)
Autrement dit, il n'y a rien de compliqué à condition d'écarter d'un
revers de main tout ce qui vient contredire ton propos.
Désolé, mais là tu me déçois. Beaucoup. J'attendais mieux de ta part.
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersPost by WykaaaLe subtyping permet de particulariser les objets, pas de les étendre.
Les étendre passe par la généricité.
par ailleurs dans ce fil, j'ai vu que Bruno ne tient pas compte de
l'héritage dans l'approche objet, soit.
J'en tiens bien sûr compte - je précisais juste que l'héritage, au
moins dans le sens où il existe comme fonctionnalité de la plupart des
langages objets, n'est pas AMHA un concept *nécessaire* à la
définition de l'OO.
L'héritage est lié au principe de classification (la taxonomie ou
taxinomie). Il permet de regrouper dans une même hiérarchie des
abstractions ayant des caractéristiques communes mais aussi des
particularismes.
Ce qui impliquent entre autres que les caractéristiques en question
soient invariantes - ce qui n'est pas le cas dans certains langages
dynamiques.
On parle de l'approche objet. Si les caractéristiques des objets ne sont
pas invariantes, on ne peut pas définir l'abstraction et on n'est donc
plus dans une approche objet.
Ah bon ? et en vertu de quelles règles ? Chapitre et verset, je te prie ?
Accessoirement, tu viens de décreter qu'aucun langage dynamique n'était
objet, puisqu'une des caractéristiques fondamentales des langages
dynamiques - je dirais même leur définition première et essentielle -
est que les objets sont eux-même dynamiques.
Je pense que ça suffit à disqualifier ta définition de "l'objet". En
fait - comme hélas la majorité des gens -, tu confond "orienté objet" et
"orienté classe".
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersPost by WykaaaMais on a besoin, dans l'approche objet d'une notion de "hiérarchie"
(au sens de relation d'ordre strict partielle entre objets). Il y en
a déjà une, issue des langages non objet, c'est l'agrégation (faible
ou forte, peut importe pour ce qui nous occupe). Dans l'approche
objet "classique", il y a une autre notion de hiérarchie, c'est
l'héritage qui permet le polymorphisme d'héritage
En quoi ce polymorphisme apporte-t'il quoi que ce soit à celui plus
générique déjà offert par la séparation entre message et comportement
? En quoi est-il nécessaire qu'un objet doive "hériter" d'un autre
pour comprendre un sous-ensemble commun de messages ?
Ce n'est pas pour "comprendre" un sous-ensemble commun de messages que
l'héritage existe mais pour identifier une classe d'abstraction ayant
des caractéristiques communes.
Dans ce cas, ce n'est donc pas la classification qui "permet le
polymorphisme d'héritage", comme tu l'écrivais n'est-ce pas, mais le
polymorphisme qui définit la (les) classification(s). Dis voir, tu n'a
pas un peu l'impression d'inverser l'effet et la cause ?-)
Peut-être me suis-je mal exprimé mais il ne faut pas confondre
l'héritage d'un point de vue conceptuel et le "polymorphisme d'héritage"
qui a besoin de quelque chose de plus pour fonctionner (le typage fort
statique ou dynamique);
s/le typage fort statique ou dynamique/le typage statique/
Et encore une fois, tu inverse la cause et l'effet. Le "plymorphisme
d'héritage" est un effet du (ou plus exactement "une restriction imposée
par") le typage statique.
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersPost by Wykaaa(qui se distingue du polymorphisme "ad'hoc" de type surcharge ou du
polymorphisme universel à la ML). Alors, en remplacement de
l'héritage, certains, dont Bruno, parlent de délégation (c'est plutôt
le vocabulaire des langages d'acteurs que des langages p"purement objet")
La notion de composition/délégation est assez fréquemment évoquée dans
la littérature, et notamment citée comme préférable à l'héritage
d'implémentation dans le GoF.
Je ne parle pas de l'héritage d'implémentation mais de l'héritage au
sens conceptuel du terme. Il est étroitement lié au concept d'abstraction.
L'héritage "au sens conceptuel du terme" - la relation "est un" en
réalité - n'est pas déterminante du polymorphisme mais au contraire
déterminée par lui. Et ce type de classification, dans un système
vraiment "orienté *objet*" - dans le sens où l'abstraction centrale est
l'objet et non la classe, laquelle n'est au mieux qu'un épiphénomène -
est généralement assez flou, voir mouvant (un même objet pouvant changer
de "classe" durant son cycle de vie).
Ce n'est donc plus la même abstraction et, dans une pure approche objet
J'aime bien les gens qui parlent de "vrai langage objet" et de "pure
approche objet" pour signifier "selon ma définition à moi de l'objet que
c'est la seule vraie même si ça contredit la moitié de la littérature
sur le sujet".
Post by Wykaaaon ne peut donc pas dire qu'il s'agit du même objet.
Ah bon, pourquoi ?
Post by WykaaaIl doit être
"re-créé" comme instance d'une autre classe.
Ah bon, pourquoi ?
Outre le fait que les notions d'"instance" et de "classe" sont
particulières à un sous-ensemble des langages objets - ces notions
n'existent pas dans les langages à prototype -, le fait pour un objet de
changer radicalement de comportement selon son état n'est pas une
nouveauté, loin s'en faut. Tu a déjà entendu parler du pattern "State" ?
Post by WykaaaPost by Bruno DesthuilliersDe ce point de vue là, ni la notion de classe ni la notion d'héritage ne
sont fondamentales de l'approche *objet*.
Ben si.
Bin non. Ces notions sont centrales dans le modèle objet dominant -
celui de, entre autres, Java et C++ (et donc d'UML etc) - mais, dois-je
le rappeler, n'existent pas dans certains langages objet, et ne sont que
des épiphénomènes. Au risque de me répéter, on parle d'orienté *objet*,
pas d'"orienté classe".
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersPost by Wykaaamais cette délégation doit tout de même respecter la notion de
hiérarchie sur les objets
Ah bon ? Et pourquoi donc ?
Par rapport à ce que j'ai dit ci-dessus
Faudra trouver autre chose alors.
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersPost by Wykaaa(on ne délègue pas à n'importe quel objet, n'importe comment).
Du moment que l'objet auquel on délègue comprend les messages qu'on
lui envoie, je ne vois pas où est le problème.
Je comprends pourquoi tu n'est pas "pour" l'encapsulation.
Mais si, bien au contraire.
Post by WykaaaLa délégation
pure peut conduire aux pires dérivent concernant la sûreté de
fonctionnement.
Mauvaise nouvelle : Y a pas de balle en argent.
De ce point de vue là, aucun système de type connu ne garanti à lui seul
la correction du programme. Ce n'est pas parce qu'un objet est
effectivement une instance d'un sous-type de XXX que son comportement en
réponse au message YYY est celui attendu.
Je suis d'accord mais au moins, on conserve la cohérence des types,
D'un point de vue formel uniquement. Si je définis une sous-classe de
File dont la méthode "write" envoie des mails d'insultes à tout ton
carnet d'adresse avant d'effacer ton disque dur, je ne suis pas sûr que
"cohérence des types" soit vraiment le terme adapté. Le fait que ce soit
techniqument une sous-classe de File nous fait une belle jambe...
Post by Wykaaace
qui réduit les erreurs potentiels sur les actions associés aux objets
Il n'y a pas d'"actions associées aux objets", il y a des objets
auxquels on envoie des messages, à eu d'en faire ce que bon leur semble
- même éventuellement de lever la main en disant "j'ai pas compris". Si
tu ne comprends pas ça, tu ne comprend pas *le* principe fondamental de
la POO, celui qui fonde Smalltalk.
Hé, moi aussi je peux asséner des grandes vérités et dire à l'autre
qu'il a rien compris simplement parce qu'il n'est pas d'accord avec moi.
Sérieusement, tu ne crois pas que plus cette discussion
s'enlise^Mavance, plus ça illustre bien mon propos premier, qui est
qu'il n'y a aucune définition théorique formelle *sérieuse et
universelle* de la POO ? Tout ça, c'est de la soupe aux cailloux... d'un
côté comme de l'autre, hein - tu a raison selon *ta* définition, j'ai
raison selon la mienne, nos définitions valent chacune ce qu'elles
valent, là n'est pas le problème, simplement elles sont incompatibles.
La seule conclusion *sérieuse* qu'on peut en tirer, c'est qu'aucune des
deux "définitions" n'a la moindre valeur scientifique (contrairement à
la théorie relationnelle, par example, qui est très clairement et
mathématiquement définie).
Post by Wykaaa(et ce, dès la compilation pour les langages à typage statique mais on
ne va pas rouvrir ce débat là... dont on a déjà longuement débattu dans
le passé)
oh bin au moins ça aide à passer les longues soirées d'hiver. Dommage
qu'on ne puisse pas en profiter pour partager une bonne bouteille en
regardant le feu !-p
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersPost by WykaaaLa délégation ne peut se faire correctement qu'en respectant cette
notion d'ordre strict entre les objets, objets de la délégation.
On a déjà eu l'occasion de comparer nos points de vues et approches du
génie logiciel - et les raisons (notamment contextuelle) pour
lesquelles ces points de vues et approches diffèrent sensiblement. En
ce qui me concerne - et même si je peux comprendre son intérêt de ton
point de vue - cette "notion d'ordre strict" n'est (AMHA etc...) pas
absolument (voire absolument pas) nécessaire, et parfois (voire
souvent) tout simplement nuisible.
Elle est nuisible uniquement quand on souhaite que les objets puissent
changer de nature dynamiquement
Non. Elle est nuisible en ce qu'elle impose des contraintes inutiles qui
ne font qu'ajouter de la complexité accidentelle sans rien garantir
quand à la correction du programme.
La correction de programme n'est effectivement pas garantie "que" par le
typage et la notion de hiérarchie. Ca se saurait et nous n'aurions pas à
débattre mais je t'affirme qu'un programme de 3000 lignes de ML qui
passe le contrôle de type a beaucoup moins de chance d'être erroné qu'un
programme écrit, par exemple, en C.
Qui est un langage à typage statique déclaratif. Et pas spécialement OO,
accessoirement. Pas plus que ML, d'ailleurs, qui reste quand même un
langage fonctionnel. Quoique, les fermetures et les objets, somme
toutes, y a quand même quelques points communs !-)
Post by WykaaaPost by Bruno DesthuilliersPost by Wykaaamais ceci conduit souvent à ce que les
objets ne soient plus intègrent ce qui peut nuire à la fiabilité du
logiciel et complique le style de programmation dit "sure" (safe
programming)
Désolé, mais je ne crois tout simplement pas qu'empiler des contraintes
résolve le problème. Crois moi, s'il suffisait de déclarer trois fois le
type d'une variable pour avoir la certitude absolue que mon programme
soit correct, je m'y plierais volontier.
Tu exagères en résumant de cette façon le typage...
Je n'exagère pas en résumant de cette façon la faillite du typage
statique déclaratif, spécialement dans le cadre d'une approche objet.
Pour le reste, je suis content que tu remarques - enfin -que j'exagère.
J'ai cru un moment que ça t'échappait.
Post by WykaaaPost by Bruno DesthuilliersLa réalité est que *ça ne
marche pas* - et non seulement ça ne marche pas, mais en plus ça
augmente de façon considérable la complexité du code, ce qui est *en
soi* une source d'erreurs.
Si tu crois que ça augmente la complexité du code sans raison, c'est que
tu as "mal" pratiqué cette approche
Bin voyons. Cet argument là, mon garçon, il est un peu facile. Je me
permets certes de te taquiner, mais pas de te prendre pour un crétin, et
je te serais reconnaissant de me créditer d'un minimum d'intelligence.
Post by Wykaaacar je n'y ai vu, pour ma part, que
des simplifications.
Ah bin oui, c'est évident. Désolé, je ne sais pas comment j'ai fait pour
ne pas me rendre compte plus tôt qu'écrire 250 lignes de boilerplate
juste pour faire plaisir au compilateur alors que mon objet, en
pratique, supportait *déjà* toutes les conditions requises
(explicitement requises - par la documentation) pour être utilisé dans
tel cas de figure. Franchement, là, je me demande.
Post by WykaaaPost by Bruno DesthuilliersAccessoirement, parmi les systèmes informatiques les plus fiables à
l'heure actuelle, certains sont implémentés dans un langage non
seulement dynamique, mais qui décourage explicitement la programmation
"défensive" (je pense bien sûr à Erlang). A mon très humble avis, il y a
là quelque chose à apprendre.
Mais Erlang n'est pas un langage objet.
Non. Encore que...
Post by WykaaaC'est plutôt un langage
fonctionnel d'acteur.
C'est toi le spécialiste des classifications et taxonomies, n'est-ce
pas. Pour ma part, tant que ça fait le boulot...
Post by WykaaaIci nous parlons de ce qui caractérise l'approche
objet. Erlang (qui est par ailleurs un très bon langage) n'a rien à
faire dans cette discussion.
Pourquoi ? Parce que ça contredit tes propos sur la nécessité du codage
défensif ?
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersEn tout état de cause, je ne vois pas en quoi cette notion est
constitutive de l'OO - même si elle constitutive du modèle objet
dominant, avec pour résultat tout un (célèbre) livre de recettes dont
le but principal est de contourner les limitations imposées par ce
modèle !-)
Ceci est une autre discussion car je ne suis pas certain que les auteurs
du livre en question aient tenu compte de tous les aspects de l'OO.
Non, en effet - la majorité des recettes en question résolvent des
problèmes spécifiques au modèle C++/Java, et n'ont que peu de sens dans
un langage dynamique. Mais ce n'est certainement pas ce à quoi tu
pensais, et ça prouve bien qu'il y a presque autant d'approches de l'OO
que d'implémentations.
Non conceptuellement, l'approche objet est quelque chose de précis.
Mon cul sur la commode.
Post by WykaaaLa
confusion est entretenue par certains courants qui veulent se rattacher
à l'objet tout en le détournant.
Ah, les affreux hérétiques, brûlons les vif. Et qu'importe s'il ne font
que nous citer les enseignement du prophète.
Post by WykaaaLa preuve dans cette discussion.
Pour moi, tout ce que cette discussion prouve, c'est que *tu* penses
qu'il y a réellement *une* définition *précise et universelle* de l'OO.
Bon, t'es un peu tout seul à le penser, mais c'est pas grave, hein...
Post by WykaaaPost by Bruno DesthuilliersPost by WykaaaPost by Bruno DesthuilliersPS : avant de vous précipiter sur vos claviers, n'oubliez pas que je
suis un joyeux troll !-)))
Faute avouée, à moitié pardonnée :-))
Mais ce n'est pas une faute !!! C'est une immense qualité, que je
revendique haut et fort !!!
Alors moi aussi :-)
DansMesBras(tm) !-)
