Ce qu'il y a de bien avec l'AS3...

Par mama, mercredi 8 août 2007 à 11:10 :: Flash :: #164 :: rss

c'est qu'on a l'impression que tout est clean, que tout est bien fait... Mais en fait c'est toujours aussi pourri et bricolé. Depuis 2 jours qu'on bosse dessus chez Yamago, que des bugs:

la valeur position de la classe Sound qui renvoie des valeurs totalement imprécises
les paramètres de composants (Inspectable) qui sont initialisés une frame après le constructeur (plus d'autres subtilités tout aussi gravos...)

Des bugs tellement enormes qu'on se demande comment ils existent encore après plus d'un an de test sur ce language. Enfin comme ca on est pas dépaysé, on sait qu'on fait du flash

Trackbacks

Aucun trackback.

Les trackbacks pour ce billet sont fermés.

Commentaires

1. Le mercredi 8 août 2007 à 12:52, par LAlex

Je sais pas comment ca se passe avec les composants de Flash, mais dans Flex 2, il faut attendre un évenement pour accédeer aux propriétés, a priori INITIALIZE si mes souvenirs sont bons (l'évenement PREINITIALIZE n'a pas encore les propriétés renseignées).

Si l'équivalent n'existe pas sur les composants CS3, c'est les composants qui sont mal foutus, pas l'AS3 ;o)

Pour la classe Sound, ben c'est sur que certaines choses n'ont pas beaucoup évoluées, notamment la synchronisation dans le temps... :-s Probablement lié à une VM pas encore assez proche du système...

++ ^_^

2. Le mercredi 8 août 2007 à 14:17, par Tek

Ce qu'il faut se dire c'est que la VM2 n'apporte des améliorations qu'à l'interpréteur du langage Actionscript. Les objets bas-niveau comme l'objet son intégrés historiquement depuis 5 versions majeures du lecteur Flash n'ont pas bougés. Tu auras avec ces objets bas-niveau toujours les mêmes erreurs qu'avec la VM1.

3. Le mercredi 8 août 2007 à 19:10, par mama

Les meta données c'est quand même des trucs qu'on code, donc la responsabilité AS3 ou Flash est quand même super limite. Le fait de devoir assigné deux fois les valeurs par défaut des paramètres pour que ca marche dans le code et dans Flash, c'est quand même bien pourri et c'etait pas comme ca en AS2

Concernant la classe Sound, ca marchait en AS2, la c'est pire, donc c'est pas la VM qui trimballe des trucs pourris c'est juste que c'est pire qu'avant

4. Le mercredi 8 août 2007 à 19:16, par foxy

Je pense comme Lalex qu'il ne faut pas faire l'amalgame entre le langage et l'IDE (voir les composants CS3), et pourtant, comme Mama j'ai super vite déchanté en utilisant ces putins de composants CS3.

C'est à se demander si le set de composant CS3 n'est pas "saboté" pour inciter les gens à basculer sur du Flex 2.

Tek > De quels objets de bas niveau parles tu ? Pourquoi conserver des "erreurs" si la VM2 est recodée entièrement (je doute que ce soit pour des raisons historiques quand même ?). Ca m'interesse si tu as des liens d'articles à ce propos.

5. Le mercredi 8 août 2007 à 20:54, par mama

Foxy je ne parle meme pas des composants V3 (c'est contre ma religion de les utiliser ;)) mais simplement des propriété Inspectable que tu peux utiliser toi même dans tes propres "composants" persos. Pour ne pas confondre j'appelerais ca des smartclips (les vieux routards s'en rappeleront ;)))

6. Le mercredi 8 août 2007 à 23:26, par LAlex

WOW, le smartclip! ;oP

Ben en fait, c'est a priori normal dans un composant UI que les propriétés n'existent pas encore dans le constructeur, étant donné que c'est un framework (a priori interne) qui les renseigne. A priori, dserrère un metatag [Inspectable] il y a une génération de code AS derrière l'IDE qui fait un truc du genre

var monComp:ComponentClass = new ComponentClass();
monComp.property = "value";

Donc, normal que les props ne soient pas présentes dans le constructeur. Il y a a priori deux manières de contourner:
- une qui aurait été propre, c'est que les composants envoient un évenement aproprié une fois les propriétés renseignées (pas de notre fait, c'est la faute à Grant ;oP)
- ben soit bidouiller, et attendre une frame pour lancer la suite des hostilités, avec un bon vieux Event.ENTER_FRAME...

Donc, je persiste: c'est le framework composant qui est franchement pas abouti... En Flex 2, c'est carrément normal d'attendre un événement avant de lancer le code d'initialisation "perso"...

++ ^_^

7. Le jeudi 9 août 2007 à 09:48, par Tek

foxy > Les objets bas niveau (je parle pas des API qu'on utilise mais bien de des objets écrit en C++ derrière) qui n'ont quasimment pas bougés dans le lecteur sont par exemple l'objet son, l'objet netconnection, l'objet qui sert à faire les loadvars/xml/loadvariables, l'objet qui fait la gestion d'ExternalInterface, SharedObject etc... Certains se sont vu rajouté des fonctionnalités comme le support de AMF3 ou autres, mais la base du code n'a pas changée.

Il n'y a pas besoin de sources pour ça, c'est une évidence pour des raisons de rétro-compatibilité avec les animations exportées pour les anciennes versions du lecteur. Ils ne se sont clairement pas amusés à dupliquer le code pour le simple plaisir de le re-écrire. Les VM1 et VM2 servent juste d'API à ces objets.

8. Le jeudi 9 août 2007 à 10:36, par mama

>>Ben en fait, c'est a priori normal dans un composant UI que les propriétés

Je précise encore une fois, je n'utilise pas de composant UI ou me sert du framework des composant de Skinner, juste de la propriété Inspectable.

Ensuite que ce soit "normal" au niveau code, a mon sens on s'en tape completement. C'est bien ca la force de Flash et de son language, c'est pas que ce soit clean "conceptuellement" c'est que ce soit efficace et opérationnel en production. Quand Macromedia a mis en place les paramètres de smartClips/composants, c'etait pour autoriser un graphiste a fournir des informations sur une instance sans mettre les mains dans le camboui.
Si du coté code il faut maintenant attendre un evenement d'initialisation (c'est possible en goretisant à mort genre ENTER_FRAME effectivement ou RENDER) ca n'a plus grand interet, la puissance de ces paramètres c'est qu'il etaient fournis au constructeur exactement comme ils le seraient via un new avec passage de paramètres. La cuisine interne du lecteur on s'en fout completement.
En Flash 5, AS1, AS2 ca marchait comme ca, la sous prétexte de cleaner le code et faire une environnement de dev solide on sacrifie à la puissance de Flash.

9. Le jeudi 9 août 2007 à 11:34, par LAlex

Je parlais pas des composants de Skinner, mais bien de la mécanique interne qui transforme la saisie d'une propriété [Inspectable] dans l'IDE en une ligne de code... (mécanique qui est faite par l'IDE Flash, et non pas par la VM)

Si c'était possible avant, c'est bien parce qu'il s'agissait de prototypes: le code généré était du type:

var newObject = {};
// Initialisation des popriétés avant appel au constructeur
newObject.property = "value";
newObject.__proto__ = ComponentClass.prototype;
newObject.__constructor__ = ComponentClass;
ComponentClass.apply(newObject);

Evidemment, c'est le genre de manip pas possible avec AS3! ;oP
Mais c'est vrai qu'un évenement qui se lance juste aprés l'initialisation des propriétés [Inspectable] et qui du coup évite la bidouille aurait été le bienvenu...

Dans l'absolu, je considère pas ca comme une réelle "perte de puissance", mais plutôt comme un changement de philosophie... C'est sur que c'est toujours asez relou de devoir changer de manière de coder pour faire une même chose dans un même soft, sauf que là on change bel et bien de langage... ;o)

++ ^_^

10. Le jeudi 9 août 2007 à 12:22, par mama

Je ne sais pas si tu te sert beaucoup de composants comportementaux dans tes développements mais le fait que ce "petit" détails a tes yeux change ne modifie pas les habitudes de travail mais fout en l'air une grosse partie de la puissance de flash.
Beaucoup de codeurs flash veulent un language soit disant clean et robuste pour faire comme les grands (Java, C++, ...) sauf que bizarrement (je parle pour le secteur du jeu spécifiquement), tous les studios de jeu se recréent des outils "graphiques" pour faciliter l'élaboration de jeux. Par exemple pour le level design. Un level designer se fout du code, il a besoin de manier des obejst graphiques dans un espace. Tous ces outils que recrée les développeurs parce qu'ils n'existent pas dans ces languages C'EST FLASH a notre niveau.
Le fait de pouvoir faire des smartclips et laisser à un game designer ou level designer la possibilité de régler un jeu sans toucher une ligne de code c'est ca la vraie puissance de ce logiciel. Bien evidemment cette facon de travailler peut s'étendre à bien plus que le jeu mais je parle de mon domaine.

En conclusion ce n'est pas le développeur et son équipe qui doivent s'adapter à l'outils mais bien l'outils à répondre aux attentes de l'équipe.

Que ce soit des prototypes ou autre chose désolé mais on s'en fout

11. Le jeudi 9 août 2007 à 22:42, par LAlex

ok, ok, pas la tête, je ferme ma gueule c'est bon...

12. Le vendredi 10 août 2007 à 11:48, par mama

j'ai pas dit ca tout de suite
Ce que je cherche a faire passer c'est que l'AS3 c'est bien beau, que ce soit le fait de l'AS3 ou de l'IDE, tout ca n'a pas d'importance. Tout simplement parce que l'AS3 sans l'IDE ca ne sert à rien (désolé pour ceux qui font du Flex mais on ne fait pas des sites ou des jeux avec Flex, on fait des graphiques, des camemberts, des backos, des outils pour développeurs...).
Donc même si l'AS3 n'est pas en cause (mais l'AS3 est en cause, la propriété position de la classe Sound c'est du code à ce que je sache ;)), si l'IDE est en cause le problème reste le même.
Le gros problème d'Adobi/Macromedia c'est qu'a chaque fois qu'une nouvelle version sort ils se concentrent sur les nouveautés sans s'assurer que le coeur de l'appli marche correctement. ComputeSpectrum c'est super mais position c'est plus important. Que des stars du web fassent des graphiques de spectres sonores c'est génial mais si a coté de ca l'ensemble des agences et studios web du monde ne peuvent proprement intégrer du son dans leurs sites web c'est autrement plus important.
Voila c'etait juste pour raller un peu et replacer l'AS3 (et Flash 9) à leur juste niveau, une nouvelle version de Flash tout aussi bancale que les précédentes mais avec plein de super trucs nouveaux qui claquent

13. Le dimanche 26 août 2007 à 03:01, par olive

le truc le plus relou avec as3 c'est que ça a l'air TRES compliqué de faire l'équivalent des "removeMovieClip()" (dans le cas général, pas juste sur un exemple avec 2 références)...

Est-ce-que vous auriez trouvé une méthodo simple pour qu'un mc puisse etre remové? (Un bon sujet pour l' "AS3 pratique", ça.. héhé)

J'ai plusieurs pistes, mais chacune me parait très pénible à suivre, et compliquée à tester dans le cas des jeux, par exemple.. Ca oblige d'adopter des mesures préventives quasiment partout:

- fonctions dispose() à tous les étages: pénible, mais si encore ça suffisait...
- obligation pour les mc A ayant des ref. vers d'autre mcs B d'écouter REMOVED sur B.

Et il ne suffit pas de se faire la "panoplie complète", faut aussi penser à la tester de temps en temps aussi..Ca va faire une nouvelle occupation assez sympathique: et hop déclenche un son ici, et hop je unload le mc.. et je vérifie que le mc est garbage collectable.. pas mal, comme passe-temps, non? Avec AS3 et le typage, on gagne vraiment du temps il parait

Je me demande si je vais pas attendre AS 3.1 histoire de laisser le temps à Adobe de proposer un truc décent.

14. Le lundi 22 octobre 2007 à 17:14, par Moi même

Bonjour,

Ce post est vieux, mais je suis tombé dessus depuis Google.

Juste un mot concernant la classe Sound et la propriété position.

Avez-vous vérifié que le son lu n'est pas en débit variable ? Parce que je ne constate pas le problème avec des mp3 encodés avec un débit fixe.

A+

15. Le vendredi 4 juillet 2008 à 15:10, par juegos para niñas

Foxy je ne parle meme pas des composants V3 (c'est contre ma religion de les utiliser ;)) mais simplement des propriété Inspectable que tu peux utiliser toi même dans tes propres "composants" persos. Pour ne pas confondre j'appelerais ca des smartclips (les vieux routards s'en rappeleront ;)))