Inscrivez-vous gratuitement
pour pouvoir participer, suivre les r�ponses en temps r�el, voter pour les messages, poser vos propres questions et recevoir la newsletter
L'interface est impl�ment�e explicitement si j'ai bien compris... La classe Student a toutes les propri�t�s d�clar�es dans l'interface Person, donc un Student est accept� l� o� un Person est attendu.Envoy� par hotcryx
Pourquoi un StringBuilder ? C'est du JS (enfin principalement), pas du C#...
Pas de questions techniques par MP ! Le forum est l� pour �a...
Tutoriels : Les nouveaut�s de C# 6 - Acc�s aux donn�es avec Dapper - Extraction de donn�es de pages web � l'aide de HTML Agility Pack - La s�rialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
On va diverger si on commence maintenant � rentrer dans le d�bat langage � typage fort / faible, mais oui, pour des raisons de maintenance (entre autre) il faut les outils pour valider ton code. Ces outils existent en JavaScript: jslint, jshint, l'analyse statique du code via les IDE (Netbeans ou autre), documentation via jsdoc, ...il y a qu'en m�me de grosses lacunes comme le typage.
cela ne peut entrainer que des erreurs d'ex�cution ou lors de conversion de type. Comme ce fut le cas en VB6 avec les Variant.
un langage ne doit pas permettre de faire tout et n'importe quoi n'importe comment. Il faut un minimum de structure sinon �a devient de la bouillie, du code spagetti...
cela dit, je n'ai rien contre toi et javascript, c'est juste mon point de vue.
je suis du m�me avis, un mauvais codeur, restera mauvais mais malheureusement on doit parfois reprendre le code d'un autre et c'est l� que �a peut coincer si le langage ne met pas des gardes fous
Je fait un fort distingo entre langage et environnement de dev te permettant de travailler sur le langage. En effet, combien de dev serait actuellement perdu sans leur Eclipse ou autre Visual Studio ch�rie.
Ici on un langage con�u au dessus de JavaScript... super, mais pour l'utiliser dans un cadre ad�quat, il faut passer par Visual Studio. Microsoft n'aurait pas mieux fait d'am�liorer leur IDE pour la reconnaissance de JavaScript ? Mais je crains que leur d�marche soit la suivante:
1 - Microsoft cr�� un langage au dessus de JavaScript (donc compatible ECMAScript 5)
2 - Microsoft teste si la communaut� est r�ceptif
3 - Si oui, alors Microsoft l'int�gre � Visual
4 - Microsoft l'int�gre � IE
5 - Microsoft force de facto la communaut� responsable des spec ECMAScript 6 � s'inspirer fortement de ce qu'ils ont impl�ment�
On se retrouve alors avec Microsoft qui fait une OPA sur JavaScript.
Juste pour infos un excellent billet de Scott Hanselman pour mieux �claircir les choses pour ceux qui y voient du flou par rapport aux autres tools d�j� dispo
marts >> arr�te de prendre les gens pour des idiots
tomlev >> pour �viter les allocations m�moires inutiles (pareil en java et C#). Dans le pass�, il me semble avoir utilis� StringBuilder (ou alors un truc �quivalent) mais pas le "+" sur des milliers d'op�rations avec Greasemonkey.
Et j'aime autant te dire que la perf sur Firefox � l'�poque (2.0) �tait tr�s tr�s rapide sur IE.
Tu as compris ... � moiti�.marts >> arr�te de prendre les gens pour des idiots
Mon propos se voulait aussi simpliste et radical que le tien.
Ce n'est pas un question de coder propement ou pas , c'est une question de productivit�.Suis-je le seul � �tre choqu� par ce type de remarque concernant JavaScript ?
J'en ai assez d'entendre que ce langage est un mauvais langage. Peu importe le langage, un mauvais codeur produira toujours du mauvais code. L'important est de ma�triser les outils que l'on a, et, d�sol� pour certains, JavaScript est langage pointu qui permet de faire de belles choses SI on s'en donne les moyens.
JavaScript n'est pas Java ou C++, donc oui, si vous voulez coder en JavaScript il vous faut d'abord apprendre � comment coder proprement.
C'est exactement le m�me d�bat que pour CSS vs SASS et LESS.
cela implique de connaitre le langage de base tout en exploitant des possibilit� s qui rendent le code plus maintenable et permettent au d�veloppeur d'�tre productif. JShint et JSlint sont des outils de v�rification de qualit� du code , pas d'analyse "statique" ou d'extension du code.
TypeScript permet d'organiser ses librairies de code dans des fichiers s�par�s afin de cr�er des composant d�pendants facilement r�utilisables , et introduit des structures qui ne seront pas adhoc avant un bon bout de temps => donc plus productif.
Et si Javascript �tait si bon que �a , pourquoi TC39 veut mettre des modules , des classes des structs , des proxys , des iterateurs des g�n�rateurs dedans si les d�veloppeurs n'en ont pas besoin ? les d�veloppeurs avaient ils besoin d'ES3.5 ?
Le but de TC39 est pr�cis : cr�er un meilleurs javascript et faire de javascript une meilleurs cible de compilation pour les langages third-party. C'est pas moi qui le dit ,c'est TC39.
Microsoft ne fait que r�pondre � un besoin.
Des solutions qui compilent vers JS il y en a des centaines d�ja : haxe, JSX , coffeescript , iced coffee , clojurescript ,emscripten ,GWT , etc ... et ce n'est pas pr�s de s'arr�ter.
Les d�veloppeurs compilent m�me du C/C++ vers javascript :
https://github.com/kripken/BananaBread/
On peut le faire en JavaScript actuellement, tout ce qui manque c'est une int�gration digne de ce nom de JavaScript dans un IDE.
Je ne jamais dit que JavaScript �tant exemp de d�fauts, le langage �volue et c'est tant mieux. Mais l� je crains que l'on parte dans une direction o� TypeScript soit de facto l'impl�mentation d'ECMAScript 6 sans passer par la case validation T39. Microsoft n'est pas Mozilla, son but s'est d'�tre rentable, alors je vois d'un mauvais oeuil autant d'�nergie d�penser pour cr�er un "nouveau" langage au lieu de cr�er un bon �cosyst�me autour de JavaScript.
Oui, mais pas de la bonne mani�re pour moi.
Tant mieux, mais apr�s il ne faudra pas se plaindre de se trouver avec des dev web qui ne savent plus comment le web fonctionne.
Microsoft a fait sortir beaucoup de framework, de tools et aujourd'hui un surlangage de javascript. D'autres g�ants aussi du logiciel le font : Preuve de la puissance de ce langage.
L'auteur de la citation suivante a bien compris :Microsoft a fait sortir beaucoup de framework, de tools et aujourd'hui un surlangage de javascript. D'autres g�ants aussi du logiciel le font : Preuve de la puissance de ce langage.
Oui mais justement, si le r�sultat est le m�me ; MS, Google, Apple auraient pas plut�t int�r�t a travailler sur un syst�me commun? Ils y gagneraient en temps de d�veloppement, en correction des bugs, en clart� aussi... etc.Citation:
au final le code g�n�r� c'est du javascript parfaitement lisible , donc m�me si demain MS abandonne typescript , les librairies g�n�r�es seront toujours totalement utilisables. Maintenant faut il apprendre typescript , coffeescript ou javascript ? d�bugger son application se fait toujours en javascript donc javascript est obligatoire , cela ne veut pas dire qu'on doit �crire du code js, c'est tout l'int�r�t de ces langages.
Ils y a une raison particuli�re qui peut justifier ces choix de d�veloppement a part autre que la concurrence?
Ecrire du code TypeScript et debugger du javascript.
Dans ce cas pour corriger un bug, il faut deja bien maitriser le javascript..faire un mapping pour savoir ou modifier...
Edit:
Il y a ca: http://www.html5rocks.com/en/tutoria...ls/sourcemaps/
Je sais ce que c'est qu'un StringBuilder, mais � ma connaissance �a n'existe pas en JS... (cela dit ma connaisance de JS est assez limit�e, je l'admets)
Au bout d'un moment il y aura surement un "JS++" qui les mettra tous d'accord. La question est de savoir s'il sera parmi les Dart, CoffeeScript et maintenant TypeScript. M'est avis que celui qui arrivera � outrepasser le JavaScript en ne g�n�rant pas de JS � partir du code �crit par le d�veloppeur et en ayant son propre moteur aura beaucoup de chances d'�tre ce langage.
Tu devrais plut�t comparer JS � d'autres langages de script comme Python ou Ruby...
et c'est toi qui d�nigre les d�vs qui ont besoin de visual studio ch�ri ?!?
si on doit se passer d'outil pour le c/c++ pour "savoir programmer", la m�me chose devrait �tre appliqu�e pour le javascript, et sans outil javascript est bien plus inutilisable que c/c++.
encore une fois le web ne fonctionne pas en javascript, faut arr�ter avec �a, le boulot de javascript pourrait �tre fait avec n'importe quel langage ... encore faut il que les extr�mistes du web arr�tent avec cette manie de consid�rer que le javacript doit �tre le seul langage du web.
Le probl�me est simple, les utilisateurs ne mettent pas leur navigateur � jour donc seul ce qui existe est utilisable pour les prochaines ann�es... d'o� les langages qui tentent d'am�liorer le JS en rajoutant des trucs et en offrant une compilation.
Si il �tait facile d'ajouter � tout le monde un nouveau langage compr�hensible par tous les navigateurs, �a ferait longtemps que �a serait fait !
A noter que contrairement � ce que certains disent, il ne faut pas forc�ment visual studio pour faire du typescript, ils ont fait un module node que tu installes en global et qui permet de compiler via une ligne de commande toute con (tsc nomdufichier), assez facile de modifier son IDE pour faire une compilation automatique � la sauvegarde ou � l'ex�cution je pense !
Et si MS s'investit autant dans le JS c'est tout simplement pour faciliter la vie des d�veloppeurs qui font des applis pour windows 8 en HTML5/JS !
Issu du blog de Scott Hanselman :
Ce type a cern� le probl�me :What I like about TypeScript - so far - is that TypeScript�s static typing could enable better tooling with warning squiggles, easy statement completion, plus smart refactoring. You also get easy navigation around code, as well as find references, rename, and more.
Voil� les avantages du typage statique, la d�tection d'erreur et le fait de rendre possible un support IDE pouss� (refactoring, auto-compl�tion etc...).
Ces choses permettent justement de travailler efficacement en �quipe, de s'y retrouver lorsque les bases de code deviennent importantes, d'�tre productif et d'�conomiser beaucoup de temps.
Dans l'�tat actuel de javascript, ceci n'est qu'� moiti� possible justement. Ce n'est pas le seul langage dans cette situation, regarde PHP, tu verras que malgr� la popularit� et les ann�es de bouteilles, aucun IDE ne peux t'offrir un support aussi avanc� que C# ou java niveau refactoring et compl�tion.
L'IDE serait quasiment oblig� d'ex�cuter le code from scratch pour savoir s'il est valide ou non.
Puis s'il vous pla�t pour ceux que cela concerne, cessez de dire que c'est au d�veloppeur de faire attention. Vous n'utiliseriez pas les m�mes variables pour stocker des doubles, des cha�nes et des pointeurs de fonction alors pourquoi tenez-vous tant � ce que ce soit possible niveau langage? En sachant que �a am�ne que des probl�mes, tant pour les interpr�teurs qui sont incapables d'optimiser, pour les IDE incapables de vous corriger, et pour vous qui risquez de vous faire avoir.
Pour ceux qui se croient tellement malins, vous �tes pas des machines mais des humains, en ce sens vous �tes faillibles et les autres membres de votre �quipe aussi. Une fois sur 1000, 10000 ou 100000 lignes de code vous utiliserez une variable de fa�on inappropri�e, �a marchera par bol dans vos tests (c'est l� le plus tra�tre) et �a posera probl�me en production.
Pour en revenir au sujet plus directement, je trouve qu'on a vraiment besoin de projets comme Dart ou TypeScript pour rendre le code JS plus s�r, plus maintenable et plus testable. Le seul point n�gatif c'est le danger de multiplication de ces JS-killers qui conduise � ce qu'aucun ne soit suffisamment r�pandu et viable.
D'accord avec toi _skip
Je serais curieux de voir le code JS g�n�r� de coffiescript...
Les codes g�n�r�s seront diff�rents, les perfs diff�rentes...
Et que faire lorsque "�a merdouille" avec le g�n�rateur!?
Voil� une question qu'il faut se poser avant d'en utiliser un.
Je pense que _skip a mis le doigt sur les principaux arguments en faveur des langages � typage statique. Apr�s, c'est s�r que les langages dynamiques ont aussi certains avantages, mais pour des grosses applications, le b�n�fice du typage statique est �vident.
Et que faire lorsque "�a merdouille" avec n'importe quel autre compilateur ? A un moment donn� il faut bien faire confiance aux outils, sinon on fait plus rien...Et que faire lorsque "�a merdouille" avec le g�n�rateur!?
_skip: Je suis plut�t d'accord avec toi sur les lacunes de JS, je t'ai donc pluss�. Comme tu l'as tr�s bien mentionn�, m�me le meilleur des cadors ne choisit pas forc�ment ceux avec qui il travaille...
Si je pr�f�re moi aussi un typage statique � un typage dynamique, ce n'est pas la seule piste. Les autres langages de script que j'ai cit� plus haut (Python et Ruby) ont aussi un typage dynamique et pourtant ils supportent mieux la mise � l'�chelle que JS parce que :
- Ils ont de v�ritables syst�mes de modules/packages, qui d�limitent les visibilit�s des symboles et permettent de bien s�parer les responsabilit�s.
- Ils ont un typage fort, qui interdit les conversions implicites. Par exemple, additionner un entier et une chaine de caract�re est consid�r� comme une erreur et lance une exception de type TypeError au lieu de faire une conversion silencieuse. �a permet par exemple de signaler au plus t�t une erreur au lieu de devoir essayer de comprendre pourquoi � la suite de plusieurs calculs, ce qu'on obtient est faux ou alors n'est pas un nombre...
Si d�j� on pouvait avoir quelque chose dans ce go�t l�, je me consid�rerais satisfait...
R�pondre avec citation
Partager