hilpers


  hilpers > comp.* > comp.objet

 #16  
05/01/2006, 11h52
Marc Boyer
Le 05-01-2006, Miguel Moquillon <moqui> a écrit :
>> 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

 #17  
07/01/2006, 11h26
zwetan
> 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 ;)

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

> 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


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...

> > 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.


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]
> > 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.


et pourquoi ?

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

> 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.


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

> 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 !


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 ?

> 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
 #18  
09/01/2006, 10h41
Miguel Moquillon
zwetan wrote:
> 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".

>> 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
 #19  
09/01/2006, 12h19
Laurent Deniau
Miguel Moquillon wrote:
> zwetan wrote:
> 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.


D'apres ces definitions, C est aussi un langage 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 :)


Tout ca aussi, C permet de le faire.

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

a+, ld.
 #20  
09/01/2006, 12h31
Laurent Deniau
zwetan wrote:
> 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.

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

> 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...

> 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.
 #21  
09/01/2006, 13h51
Miguel Moquillon
Laurent Deniau wrote:
> 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"

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

> 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.

> 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.
 #22  
09/01/2006, 15h16
Laurent Deniau
Miguel Moquillon wrote:
> Laurent Deniau wrote:
>> 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.

> 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.

> 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.

>>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.
 #23  
09/01/2006, 16h33
Miguel Moquillon
Laurent Deniau wrote:
> 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.

> - 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.

> - 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;
}
 #24  
09/01/2006, 17h54
Laurent Deniau
Miguel Moquillon wrote:
> Laurent Deniau wrote:
>> 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.


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.

> 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.


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".

>>- 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.

> 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.
 #25  
10/01/2006, 00h19
zwetan
"Miguel Moquillon" wrote:
> 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.


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
[..]
[..]
[..]
[..]
[..]
[..]
[..]

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
[..]

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.

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


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
[..]

ou utiliser des fonctions de continuation plutot que des fonctions
reccursives
[..]

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
[..]

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.

> A côté de ceci, sauf erreur de ma part, tu sembles faire la distinction
> entre langage objet et langage orienté objet. [snip]
> 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 :)

> 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
 #26  
10/01/2006, 00h46
zwetan
"Laurent Deniau" wrote:
[snip]
> 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
[..]

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.

> 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:
[..]

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

> 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
 #27  
10/01/2006, 09h49
Miguel Moquillon
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
 #28  
10/01/2006, 10h16
Miguel Moquillon
Laurent Deniau wrote:

> 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.


> C:
> 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.

> 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.

> 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.

> 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) 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).
 #29  
10/01/2006, 11h19
Laurent Deniau
Miguel Moquillon wrote:
> Laurent Deniau wrote:
>>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.

>>C:
>>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


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

> 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.

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

> 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.
>>>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.

> 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.


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.
 #30  
10/01/2006, 14h21
Miguel Moquillon
Laurent Deniau wrote:
> 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.


> 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


Discussions similaires
Un composant ActiveX ne peut pas créer l'objet avec un objet Scripting.FileSystemObject

9telecom degroupé total vers free dégroupé total (?)

Inversion du sous-total imbriqué et du sous-total externe

comment obtenir un total et sous total des données affichés d'un .


Fuseau horaire GMT +2. Il est actuellement 10h55. | Privacy Policy