Hello :) En AS2 tu as la possibilité de faire de l'injection dans le prototype d'une classe de nouvelles méthodes car l'AS2 reste de l'AS1 et la possibilité d'utiliser le #include permet d'améliorer les classes natives du player (MovieClip, Array, etc...) maintenant pour ajouter des méthodes dans le prototype on se rend vite compte que dans MTASC sans le #include cela devient super compliqué.
Sinon dans GAForFlash il nous a fallu trouver une technique pour utiliser un code qui devait obligatoirement être en double... code énorme sans avoir à maintenir plusieurs classes avec le même code et du coup avoir la difficulté au niveau des tests etc de devoir pour tout changement dans une classe avoir à changer toutes les autres classes aussi et le include en AS3 a aussi sa place. Aucun rapport entre OOP et le include :) c'est comme si en AS3 tu as les metadata et que pas possible de s'en servir car tu trouves cela inutile :) On a bien vu ce problème dans FlashCS3 qui n'utilise pas le MXMLC.exe pour compiler en FP9 et du coup il faut faire un code pour Flash CS3 et un code pour les swf compilés avec le MXMLC.exe ... dans FLASH CS4 nous pouvons enfin travailler avec un code compatible Flex/Flash identique mais le mal est fait. Bref... ce qui peut paraitre inutile au final peut sembler pas si inutile que cela. Même au niveau de Adobe avec l'AS3 nous souffrons déjà des choix fait par Adobe sur le langage avec quelques suppressions dans le langage qui semblent bien étranges, exemple : - pas de apply dans le constructeur et d'accés au constructeur (la fonction).. ce qui complique beaucoup de choses - pas de private sur le constructeur, là dessus voilà l'exemple inverse car pour ma part je n'ai pas besoin du tout de ce mot clé sur le constructeur (disons que son absence ne me dérange pas du tout) mais malgré tout pas mal de développeur pensent en avoir besoin - etc... Il y a un standard ECMAScript... si tu prends par exemple le switch..case dans Haxe tu penses qu'il est standard ? Ou la gestion des erreur avec les throw ? Moi non et cela me dérange aussi là dessus :) C'est un peu comme Microsoft et silverlight ou IE... font un peu leur vie avec les standards ECMAScript.. avec maintenant ECMAScript harmony .. pfff soit disant qu'il faut alléger le langage et en faire un truc "simple" ... désolé mais non :) Le langage est riche .. tant mieux ... faut pas le brider juste par caprice ou par ce que l'on pense ne pas avoir besoin d'une fonctionnalité. Ensuite il est clair que cela peut aider à simplifier peut être l'implémentation de virer des choses dans le langage (cf l'AS3 bridé... même si une partie peut être due au problème de norme ES4 non finalisée... tout est discutable) EKA + :) Le 11 février 2009 02:39, Dr. Benton <[email protected]> a écrit : > > C'est sûr que vu comme ça, avec un développeur d'un coté et une > escouade d'ingénieurs des plus grosses boites IT du monde de l'autre, > c'est un peu David contre Goliath, et Haxe n'a que peu de chance de se > faire une place face à un Tamarin qui pourrait effectivement devenir > omniprésent. > > Et même si ce serait sûrement une très bonne chose que de voir l'usage > de Tamarin se généraliser à tout un éventail d'utilisations possibles, > et peut-être devenir le fameux "Next Big Language" coté client comme > serveur, je ne peux m'empêcher d'avoir une préférence "affective" pour > Haxe, et pour son auteur qui a l'époque a révolutionné le > développement AS2 avec MTASC. > MTASC, qui nous a permis le premier de nous affranchir de l'IDE Flash, > changeant par là-même complètement les processus de travail et donnant > un coup de boost phénoménal à la productivité des développeur AS2, et > qui bien que développé par une seule personne était bien plus rapide > que le compilateur de Macromedia, l'une des plus grosses boîtes du Web > à l'époque. > (pour l'anecdote, je suis complètement d'accord avec la suppression du > #include dans MTASC, qui n'avait à mon humble sens rien à faire dans > une logique orientée Objet ; à l'époque cela m'avait obligé à > supprimer les quelques includes que mon framework maison contenait, et > celui-ci s'en était trouvé bien mieux architecturé) > > Tout cela étant dit, sur le fond je suis d'accord, et je serai le > premier à utiliser Tamarin pour autre chose que pour du Flash lorsque > cela sera possible :) > > > > --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de Google Groupes. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour afficher d'autres options, visitez ce groupe à l'adresse http://groups.google.com/group/FCNG?hl=fr -~----------~----~----~----~------~----~------~--~---
