Discussion :

[Engiwip]

Bonjour .
Avec babel , les spec ES7 et flow pour javascript nous pouvons profiter encore de l �cosyst�me javascript c�t� client comme cote serveur avec un typage fort et une structure js plut�t agr�able

Alors Typescript pour quelle utilit� ?

[Marco46]

Pour avoir tout en un.

Je ne connais pas les diff�rences exactes entre flow et TypeScript mais il doit y en avoir.

Vue3 a fait le choix de TypeScript aussi. On voit aussi de plus en plus de projets React avec du TypeScript. Et Ryan Dahl r��crit son reboot de node avec TypeScript actif out of the box.

C'est clairement un choix tr�s solide.

EDIT : Le vrai danger avec TypeScript c'est de le confondre � la va-vite avec un langage de la cat�gorie Java / C#. Ca n'a absolument aucun rapport. C'est juste un superset de JS, pas du tout un langage � part enti�re.

Du coup il faut vraiment �viter de chercher absolument � imiter un design de type POO comme avec Java / C#. C'est � mon sens la plus grosse erreur de Angular dont le m�canisme d'injection de d�pendances est le plus gros avatar.

Comme l'a dit le lead dev de TypeScript dans un de ses tweets :

"I'm using TypeScript so I have to write OOP code with classes" :: "I got a paintbrush from Home Depot so I have to paint my house orange"

[Engiwip]

Salut.
Je vois bien les avantages de la OOP. Mais n est ce pas inutile au final ?
Avec l orientation que prennent l ecritures des services comme des fonctions ,la fin de l h�ritage pr�f�r� a la composition.
L aspect modulaire et asynchrone de node . Je n ai pas trouv� l utilit� des patterns oop de typescript.
Au final Ca rajoute une couche de transpilation donc de complexite en plus.

Puis quand on voit des api entieres cod�es en golang on doit pour voir se passer des generics et autre prototype en node cote serveur et javascript cote client.
...

En fait je ne suis pas convaincu que Typescript s inscrive dans la dur�e pour que ca devienne un choix incontournable .


De nouveau acteurs comme rust- nucleon ou kotlin sur javascript permettent la m�me promesse que Typescript avec la possibilit� d apprendre kotlin pour d autre utilit� comme le mobile.

[Marco46]

Je n ai pas trouv� l utilit� des patterns oop de typescript.

Mais justement, c'est ce que j'ai �crit dans mon message pr�c�dent, il n'y a aucune obligation � faire de la POO avec TypeScript. Aucune.

Il n'y a pas de pattern OOP dans TypeScript. C'est un syst�me de typage statique structurel qui n'a aucun impact au runtime (sauf si tu �cris des types guards ce qui peut se r�v�ler tr�s utile).

Au final Ca rajoute une couche de transpilation donc de complexite en plus.

Babel aussi. La phase de transpilation permet de cibler le plus bas d�nominateur commun que tu devras supporter en terme de version du JavaScript OK sur tes moteurs d'ex�cutions cibles.

En gros si t'as IE11 dans la liste tu cibles E5. Sinon tu remontes au fur et � mesure, cf les Kangax tables.

La transpilation ne sert pas seulement � ajouter un syst�me de typage, �a permet de faire le m�me boulot que Babel avec en plus le syst�me de typage.

TypeScript c'est JavaScript normal + un syst�me de type � la phase de transpilation.

Puis quand on voit des api entieres cod�es en golang on doit pour voir se passer des generics et autre prototype en node cote serveur et javascript cote client.

Je ne comprends pas trop le rapport avec Golang. Le fait de typer permet d'avoir des contrats clairs quand tu d�couples les diff�rentes parties de ton appli.

Au cours des derniers mois j'ai migr� 2 applis en JavaScript vers TypeScript, d'abord une appli front de ES5 avec des IIFE vers TypeScript (grosse gal�re) et ensuite une appli back (type outil CLI, pas API) de ESNext � TypeScript et j'en suis tr�s content.

J'�tais vraiment tr�s sceptique sur TS et au final je trouve que �a clarifie consid�rablement les choses, il faut par contre se taper une phase d'apprentissage assez longue parce que ce n'est pas ce qu'on pense de prime abord. Ce n'est pas du Java ou du C# adapt� � JS. Rien � voir.

�a a aussi l'avantage d'�tre, je trouve, beaucoup plus simple � utiliser que Babel et ses multiples modules.

Apr�s est-ce que c'est obligatoire ? Je ne pense pas. Mais c'est un vrai confort, en particulier pour d�finir tes mod�les de donn�es et jouer avec.

En fait je ne suis pas convaincu que Typescript s inscrive dans la dur�e pour que ca devienne un choix incontournable .

Les exemples que je t'ai cit� (Vue3, deno, ...) semblent montrer que si.

Mais on y est pas encore. Quand deno commencera � remplacer node l� je pense que �a va vraiment acc�l�rer les choses. Mais c'est � un horizon 5 ans minimum. Ce reboot de node r�sout des probl�mes insolvables dans l'architecture actuelle qui sont fondamentaux, et � terme �a va favoriser deno au profit de node. �videmment c'est de la pr�diction � 2 balles sur un forum mais je le sens bien

De nouveau acteurs comme rust- nucleon ou kotlin sur javascript permettent la m�me promesse que Typescript avec la possibilit� d apprendre kotlin pour d autre utilit� comme le mobile.

Ce n'est pas comparable avec TypeScript.

Il s'agit ici de prendre un langage A et de le transpiler en un langage B.

TypeScript c'est un langage A + des extensions qui transpile en un langage A sans les extensions.

C'est tr�s diff�rent comme concept. Tout code JS est un code TS compatible.

[Paleo]

Bonjour .
Avec babel , les spec ES7 et flow pour javascript nous pouvons profiter encore de l �cosyst�me javascript c�t� client comme cote serveur avec un typage fort et une structure js plut�t agr�able

Alors Typescript pour quelle utilit� ?

Bonjour, la question est � l'envers. On n'a pas besoin de justifier pourquoi choisir le leader plut�t que le challenger. En revanche on pourrait se demander :

- Pourquoi Hack plut�t que PHP ?
- Pourquoi Yarn plut�t que Npm ?
- Pourquoi Cassandra plut�t que HBase ?
- Pourquoi Flow plut�t que TypeScript ?

J'ai pour ma part un doute sur la p�rennit� de Flow, car sa base d'utilisateurs me semble tr�s attach�e � la galaxie React. Or, React est un framework frontend, et les leaders des frameworks frontends ne le restent que quelques ann�es.

� part �a, il n'y a pas de rapport entre TypeScript et l'OOP. Il y en avait un il y a six ans, lorsque 6to5 (devenu Babel) n'existait pas et que la seule mani�re d'avoir des classes dans la future syntaxe de JavaScript �tait TypeScript. Ce sont de bons souvenirs, mais nous ne sommes plus en 2013.

Derni�re remarque : ES2016 (ES7) a trois ans. C'�tait avant async / await. Nous en sommes � ES2018.

[Engiwip]

j'aime bien tes remarques
je reponds � maniere sans conflit , pour j'espere faire avancer le bouzin.

Mais justement, c'est ce que j'ai �crit dans mon message pr�c�dent, il n'y a aucune obligation � faire de la POO avec TypeScript. Aucune.

La transpilation ne sert pas seulement � ajouter un syst�me de typage, �a permet de faire le m�me boulot que Babel avec en plus le syst�me de typage.

TypeScript c'est JavaScript normal + un syst�me de type � la phase de transpilation.

ok donc je ne vois pas d'utilit� � prendre TypeScript

Je ne comprends pas trop le rapport avec Golang. Le fait de typer permet d'avoir des contrats clairs quand tu d�couples les diff�rentes parties de ton appli.

oui tu as raison je me suis mal exprim� . Je voulais dire que l'exemple de l'utilisation d'un langage comme golang revient vers plus de simplicit�. donc avec les fonctionnalit�s de javascript �� devrait suffire pour mener � bien un projet nodejs. sans superset.

Au cours des derniers mois j'ai migr� 2 applis en JavaScript vers TypeScript, d'abord une appli front de ES5 avec des IIFE vers TypeScript (grosse gal�re) et ensuite une appli back (type outil CLI, pas API) de ESNext � TypeScript et j'en suis tr�s content.

J'�tais vraiment tr�s sceptique sur TS et au final je trouve que �a clarifie consid�rablement les choses, il faut par contre se taper une phase d'apprentissage assez longue parce que ce n'est pas ce qu'on pense de prime abord. Ce n'est pas du Java ou du C# adapt� � JS. Rien � voir.

ok mais s'il a fallu une phase d'apprentissage assez longue . je n'en vois l'utilit� au final.
enfin �� t' a permis de t'eclater dans ton dev c'est d�j� ��.

�a a aussi l'avantage d'�tre, je trouve, beaucoup plus simple � utiliser que Babel et ses multiples modules.

d�sol� je ne vois pas le rapport au niveau de la simplicit� , Babel c'est une d�claration dans le fichier json tout en profitant de l'ecosystem des packages npm par la suite

Apr�s est-ce que c'est obligatoire ? Je ne pense pas. Mais c'est un vrai confort, en particulier pour d�finir tes mod�les de donn�es et jouer avec.



Les exemples que je t'ai cit� (Vue3, deno, ...) semblent montrer que si.

Mais on y est pas encore. Quand deno commencera � remplacer node l� je pense que �a va vraiment acc�l�rer les choses. Mais c'est � un horizon 5 ans minimum. Ce reboot de node r�sout des probl�mes insolvables dans l'architecture actuelle qui sont fondamentaux, et � terme �a va favoriser deno au profit de node. �videmment c'est de la pr�diction � 2 balles sur un forum mais je le sens bien



Ce n'est pas comparable avec TypeScript.

Il s'agit ici de prendre un langage A et de le transpiler en un langage B.

TypeScript c'est un langage A + des extensions qui transpile en un langage A sans les extensions.

C'est tr�s diff�rent comme concept. Tout code JS est un code TS compatible.

Ok �� a le merite d'etre clair

[Engiwip]

Bonjour ,
je tente une r�ponse.

Bonjour, la question est � l'envers. On n'a pas besoin de justifier pourquoi choisir le leader plut�t que le challenger.

la question est tout � fait � l'endroit , tu viens d'y repondre toi meme.
pourquoi choisir le challenger quand on a le leader. et que l'existence du challenger d�pend uniquement de la presence et pertinence du leader

J'ai pour ma part un doute sur la p�rennit� de Flow, car sa base d'utilisateurs me semble tr�s attach�e � la galaxie React. Or, React est un framework frontend, et les leaders des frameworks frontends ne le restent que quelques ann�es.

je ne comprends pas cette logique d'opposer front end au backend avec javascript.
on utilise bien javascript avec nodejs cot� server . donc tout ce qui est permis au front est permis au back ( en lib javascript j'entend)
sinon qu'elle utilit� de prendre un backend en javascript si ce n'est pour beneficier de l"ecosysteme global ?

on n'est pas oblig� d'utiliser les conventions commonjs cot� node mais on peut prendre les dernieres spec ES2018 et faire de beaux import avec des accolades
enfin bref tout �� pour dire que Flow cot� serveur prend tout son sens .

� part �a, il n'y a pas de rapport entre TypeScript et l'OOP.

bah un peu quand meme ,constructor , class , interface , generic c'est un peu de l'OOP non ?

Derni�re remarque : ES2016 (ES7) a trois ans. C'�tait avant async / await. Nous en sommes � ES2018.

c'est exact Async await c est es2017 mais c est pas grave. Hein on ne va pas me faire un proces pour ne pas conna�tre par coeur la nomenclature de ecsmascript
Du coup quelle avanc�e tu retiens de ES2018?

[Paleo]

En fait je ne suis pas convaincu que Typescript s inscrive dans la dur�e pour que ca devienne un choix incontournable.

Ce sont deux points distincts.

1. TypeScript va durer. Il est devenu LE moyen de documenter une API. La base des d�finitions accessible par "@types/" est gigantesque et aujourd'hui de nombreux programmeurs JavaScript se pr�occupent eux-m�me de publier les typages directement dans leurs packages. Il n'y a pas du tout l'�quivalent sur Flow.

En outre, TypeScript est un pilier de la nouvelle strat�gie ouverte de Microsoft. L'IDE VS Code est cod� en TypeScript, et avec le tout nouveau Azure Data Studio qui en reprend l'apparence, je me demande si VS Code ne deviendrait pas un framework multi-OS modulable. Toujours sur le fait que Microsoft prenne la technologie au s�rieux : JavaScript est aussi devenu un citoyen de premi�re classe sur Windows, et Anders Hejlsberg (Turbo Pascal, Delphi, DotNet) contribue activement � TypeScript.

2. TypeScript restera toujours un choix optionnel par rapport � JavaScript. Donc pas un choix incontournable. � part peut-�tre sur l'aspect documentation.

pourquoi choisir le challenger quand on a le leader. et que l'existence du challenger d�pend uniquement de la presence et pertinence du leader

TypeScript est en concurrence avec Flow, pas avec JavaScript. TypeScript est JavaScript, plus du typage. Tout comme Flow.

enfin bref tout �� pour dire que Flow cot� serveur prend tout son sens.

Je n'ai pas dit le contraire. La p�rennit� d'une technologie d�pend beaucoup du nombre d'utilisateurs. Si l'on retire les d�veloppeurs React, il ne reste plus beaucoup d'utilisateurs de Flow. Et React ne restera pas �ternellement leader sur son cr�neau. Ce qui pose la question : Flow est-il inscrit dans la dur�e ?

bah un peu quand meme ,constructor , class , interface , generic c'est un peu de l'OOP non ?

JavaScript int�gre les outils pour l'OOP : les classes et les constructeurs font partie de JavaScript depuis 4 ans (ES2015).

Les interfaces et les types g�n�riques de TypeScript ne sont pas caract�ristiques de la programmation orient�e objets.

[Marco46]

ok donc je ne vois pas d'utilit� � prendre TypeScript

Alors tu ne vois pas non plus celle de flow ?

oui tu as raison je me suis mal exprim� . Je voulais dire que l'exemple de l'utilisation d'un langage comme golang revient vers plus de simplicit�. donc avec les fonctionnalit�s de javascript �� devrait suffire pour mener � bien un projet nodejs. sans superset.

Oui tu peux.

ok mais s'il a fallu une phase d'apprentissage assez longue . je n'en vois l'utilit� au final.
enfin �� t' a permis de t'eclater dans ton dev c'est d�j� ��.

Le code est je trouve beaucoup plus clair �a te force � avoir un certain niveau de qualit�.

Je ne pense pas que �a r�duise les bugs, dans le sens o� c'est la mani�re d'automatiser les tests qui est la plus importante � ce niveau mais �a am�liore grandement la lisibilit�. Et comme tous les outils il y a une phase d'apprentissage c'est normal. Ca sera pareil avec flow ou n'importe quoi d'autre.

d�sol� je ne vois pas le rapport au niveau de la simplicit� , Babel c'est une d�claration dans le fichier json tout en profitant de l'ecosystem des packages npm par la suite

Il faut importer le package principal mais aussi tout ce que tu veux utiliser comme plugin et aussi flow du coup. Avec TypeScript tu importes TypeScript, point final.

C�t� linter tu remplaces ESLint avec TSLint qui est vraiment tr�s bien.

[Marco46]

la question est tout � fait � l'endroit , tu viens d'y repondre toi meme.
pourquoi choisir le challenger quand on a le leader. et que l'existence du challenger d�pend uniquement de la presence et pertinence du leader

Sauf que tu inverses les termes. Le leader c'est tr�s clairement TypeScript.

bah un peu quand meme ,constructor , class , interface , generic c'est un peu de l'OOP non ?

Tu peux parfaitement d�velopper dans un style fonctionnel avec tout �a. C'est m�me tr�s agr�able d'avoir du typage sur des fonctions pures.

[Engiwip]

Ce sont deux points distincts.

1. TypeScript va durer. Il est devenu LE moyen de documenter une API. La base des d�finitions accessible par "@types/" est gigantesque et aujourd'hui de nombreux programmeurs JavaScript se pr�occupent eux-m�me de publier les typages directement dans leurs packages. Il n'y a pas du tout l'�quivalent sur Flow.

En outre, TypeScript est un pilier de la nouvelle strat�gie ouverte de Microsoft. L'IDE VS Code est cod� en TypeScript, et avec le tout nouveau Azure Data Studio qui en reprend l'apparence, je me demande si VS Code ne deviendrait pas un framework multi-OS modulable. Toujours sur le fait que Microsoft prenne la technologie au s�rieux : JavaScript est aussi devenu un citoyen de premi�re classe sur Windows, et Anders Hejlsberg (Turbo Pascal, Delphi, DotNet) contribue activement � TypeScript.

2. TypeScript restera toujours un choix optionnel par rapport � JavaScript. Donc pas un choix incontournable. � part peut-�tre sur l'aspect documentation.


TypeScript est en concurrence avec Flow, pas avec JavaScript. TypeScript est JavaScript, plus du typage. Tout comme Flow.

.

ok Tout ceci m'eclaire profondement .merci.

Je n'ai pas dit pas le contraire. La p�rennit� d'une technologie d�pend beaucoup du nombre d'utilisareurs. Si l'on retire les d�veloppeurs React, il ne reste plus beaucoup d'utilisateurs de Flow. Et React ne restera pas �ternellement leader sur son cr�neau. Ce qui pose la question : Flow est-il inscrit dans la dur�e ?

bonne question.
du coup j'en ai une autre : est ce que les dev du projet nodejs ambitionnent de tout r�ecrire en typescript ?

Les interfaces et les types g�n�riques de TypeScript ne sont pas caract�ristiques de la programmation orient�e objets.

?
a partir du moment ou ceci aide a modeliser , definir un comportement ou un contrat, etc les interfaces et generics font partie de la POO.
mais l� ce n'est plus le sujet

[Engiwip]

Le code est je trouve beaucoup plus clair �a te force � avoir un certain niveau de qualit�.

Je ne pense pas que �a r�duise les bugs, dans le sens o� c'est la mani�re d'automatiser les tests qui est la plus importante � ce niveau mais �a am�liore grandement la lisibilit�. Et comme tous les outils il y a une phase d'apprentissage c'est normal. Ca sera pareil avec flow ou n'importe quoi d'autre.

Il faut importer le package principal mais aussi tout ce que tu veux utiliser comme plugin et aussi flow du coup. Avec TypeScript tu importes TypeScript, point final.

C�t� linter tu remplaces ESLint avec TSLint qui est vraiment tr�s bien.

ok c'est pertinent . je ne suis pas born� hein ? mais j'hesite avant de plonger.

[Paleo]

est ce que les dev du projet nodejs ambitionnent de tout r�ecrire en typescript ?

Pas � ma connaissance. Le projet de refaire Node.js avec typeScript, c'est Deno, d�j� signal� plus haut par l'ami Marco46. Il faudra attendre quelques ann�es pour voir ce que �a donne.

?
a partir du moment ou ceci aide a modeliser , definir un comportement ou un contrat, etc les interfaces et generics font partie de la POO.
mais l� ce n'est plus le sujet

La POO implique des hi�rarchies de classes. Les interfaces ou les types g�n�riques sont des outils de documentation du code. Par exemple o� serait la POO selon toi dans ce code :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
 
interface FormatTextOptions {
  startSentenceWithCapitalLetter?: boolean
  fixSpaces?: boolean
  fixQuotes?: boolean
}
 
function formatText(text: string, options: FormatTextOptions = {}) {
  // ...
  return text;
}

[Engiwip]

Bah sous tes yeux.
Tu as un objet compose par les �l�ments de l interface.
On revoit les design pattern ?

[Marco46]

Pour �tre complet il faut citer l'article de Eric Elliott, The TypeScript Tax qui est devenu un classique sur ce sujet (14K claps sur medium c'est vraiment �norme).

Il va plut�t dans le sens de ne pas utiliser TypeScript sur de grosses applis en production.

Je l'avais lu en janvier et je viens de voir qu'il a mis � jour certaines choses. Les commentaires sont aussi int�ressants � lire.

[Paleo]

L'avis d'Eric Elliott est valable dans le contexte de la programmation fonctionnelle, car il est en effet difficile de typer des fonctions d'ordre sup�rieur (des fonctions qui retournent des fonctions). La version 3.4 de TypeScript, sortie cette semaine, am�liore les choses.

Bah sous tes yeux.
Tu as un objet compose par les �l�ments de l interface.
On revoit les design pattern ?

Tu devrais surtout revoir les d�finitions. Pas de classes ou d'h�ritage, pas de POO. En JavaScript on peut manipuler des objets sans faire de POO.

[Engiwip]

Tu devrais surtout revoir les d�finitions. Pas de classes ou d'h�ritage, pas de POO. .

Okay ....bon je te souhaites un bon we merci pour ce moment.

[Engiwip]

Pour �tre complet il faut citer l'article de Eric Elliott, The TypeScript Tax qui est devenu un classique sur ce sujet (14K claps sur medium c'est vraiment �norme).

Il va plut�t dans le sens de ne pas utiliser TypeScript sur de grosses applis en production.

Je l'avais lu en janvier et je viens de voir qu'il a mis � jour certaines choses. Les commentaires sont aussi int�ressants � lire.

mince marco tu m'avais presque convaincu ...
retour � la case d�part alors ?

[Marco46]

L'avis d'Eric Elliott est valable dans le contexte de la programmation fonctionnelle, car il est en effet difficile de typer des fonctions d'ordre sup�rieur (des fonctions qui retournent des fonctions). La version 3.4 de TypeScript, sortie cette semaine, am�liore les choses.

J'ai pas encore regard� TS3.4 mais perso je fais ce genre de choses :

Code typescript :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
declare type MapParsedDocumentFnType = (mdParsedDocument: IMdParsedDocument) => ITargetDocument;
declare type UnConfiguredMapParsedDocumentFnType = (conf: { markedOptions: MarkedOptions }) => MapParsedDocumentFnType;

Apr�s je fais encore beaucoup de conneries avec ce paradigme, pas assez d'exp�rience et tr�s difficile de trouver des missions pour progresser, mais je trouve �a tr�s simple et �a fait le boulot pour mes projets perso.

mince marco tu m'avais presque convaincu ...
retour � la case d�part alors ?

Je te donne un avis pour, donc par honn�tet� intellectuelle je te donne aussi un avis contre. Apr�s Eric Elliott n'est pas particuli�rement contre l'usage de TypeScript, il dit en gros que le gain n'en vaut pas la d�pense grosso modo pour les m�mes raisons que tu avances, c'est � dire que l'�cosyst�me JS est d�j� tr�s fourni. Mais je suis moyennement d'accord parce que �a suppose d'aller farfouiller dans beaucoup d'outils diff�rents alors qu'on a beaucoup de choses d'un coup avec TS.

C'est pas son seul argument, cf remarque de Paleo.

Je te fournis aussi ce lien parce qu'il est en plein dans le sujet et que c'est une r�f�rence internationale, cette question servira certainement � d'autres lecteurs.

Concernant le d�bat sur la POO, je suis du m�me avis que Paleo. L'exemple qu'il a fourni contient une fonction first class, je vois mal comment tu peux consid�rer �a comme de la POO. La m�me impl�mentation en POO partirait d'une classe TextFormatter impl�mentant une fonction format avec toute une hi�rarchie de classes pour mutualiser les m�canismes de formatage.

[Engiwip]

J'ai pas encore regard� TS3.4 mais perso je fais ce genre de choses :

Je te donne un avis pour, donc par honn�tet� intellectuelle je te donne aussi un avis contre. Apr�s Eric Elliott n'est pas particuli�rement contre l'usage de TypeScript, il dit en gros que le gain n'en vaut pas la d�pense grosso modo pour les m�mes raisons que tu avances, c'est � dire que l'�cosyst�me JS est d�j� tr�s fourni. Mais je suis moyennement d'accord parce que �a suppose d'aller farfouiller dans beaucoup d'outils diff�rents alors qu'on a beaucoup de choses d'un coup avec TS.
.

l'article que tu as donn� est top
vos exemples aussi.
�� donne � r�fl�chir.

merci � vous deux

pour la POO , il n' y a pas de d�bat ouvert , �� ne m'interesse absolument pas d'avoir tort ou raison .
on ne cherche pas � piloter un systeme par le langage comme on le ferait en C ou en Go , on ne cherche pas � gerer l'espace d'adressage , faire de l'IOT etc..

,ce sont des objets qu'on manipule , les interfaces permettent de d�finir un comportement , de pratiquer la composition.
a partir du moment ou tu d�couples la complexit� et que tu d�finis un comportement de classe ici dans le cas du formatter , on fait de la POO .
pas besoin de se faire un noeud au cerveau , c'est de la POO d�s que tu penses � l'application d'un pattern .

et chaque langage moderne implemente plus ou moins bien des paradigmes de POO selon la finalit� du langage

pour moi �� commence ici la programmation objet , sinon c'est de la prog systeme voir du scripting bash . bref �� ne m'interesse pas ce d�bat sur des mots ou sur la philosophie des concepts .
la POO n'est pas que du polymorphisme, , de l' heritage multiple , etc .