AS3 or not AS3?

Pendant ma lecture du très bon bouquin "Essential Actionscript 3.0" par Moock, j'ai noté les fonctionnalités nouvelles intéressantes pour la programmation des jeux:

• possibilité de changer dynamiquement le parent d'un clip avec addChild(). Si un clip personnage rentre dans un clip véhicule, ou un clip batiment, il peut être plus pratique de mettre "physiquement" le personnage DANS le clip vehicule (et gérer ainsi la depth du perso au sein du véhicule). En AS1/2, il faudrait supprimer le personnage du clip dans lequel il était, et faire un attachMovie() dans le nouveau clip destination (+ implémenter une fonction clone() pour restituer son état interne à l'identique).
  
• possibililité du dupliquer des SWF chargés dans faire de reload. (pratique dans un jeu ou les levels sont des SWF externes, mais que chacun des levels peut utiliser des ressources communes: monstres, bonus, etc... eux-mêmes dans des SWF externes.)
  
• propriété currentLabels: pratique pour les connaître les animations disponibles dans une marionnette.
• on peut espérer (je dis bien espérer) avoir un meilleur controle du framerate avec la propriété stage.framerate.
• les meilleures performances, maintes fois louées, ne semblent s'appliquer qu'au traitement massif de données (XML, regExp, 3D, etc..). Dés qu'il s'agit de traitement basique, il semblerait que les perfs soit plutôt moins bonnes (mais juste un peu ): cf. petit essai ici.
  

Bon, bon... alors en gros, la grande nouveauté - avec de réelles potentialités pour le jeu - est la display List.

Cependant, elle amène une énorme contrainte: il n'est désormais pas possible de faire un removeMovieClip "bourrin". Un simple removeChild(obj) va retirer obj de l'affichage, sans pour autant le supprimer de la mémoire.

Pour supprimer complètement un objet, nous dit la doc, et relayée par les flash-gourous:

1. il faut réaliser une fonction de "remove" qui soit récursive, c-à-d qui supprime un par un tous les sous-objets de obj (afin que chaque sous-obj reçoive Event.REMOVED, et donne ainsi une possibilité de traiter l'évenement).
2. il faut que cet objet et ses-objets prévoient la possibilité permanente d'être "removés", que ce soit par une fonction dispose(), ou en écoutant le message Event.REMOVED.
3. il faut supprimer toutes les références à cet objet, ou à des sous-objets de ce dernier. Donc si un objet utilisateur contient une référence vers un objet utilisé, il faut systématiquement écouter Event.REMOVED pour supprimer la référence si d'aventure l'objet était supprimé.
4. Il faut semble-t-il stopper dans obj et ses sous-obj tous les sons, arréter toutes les têtes de lectures, stopper tous les timers, etc.. (cf. page 807). La question que je me pose (pas encore tester), c'est: comment le Flash Player implémente t-il les image-clés vides? Fait-il un removeChild() ? Si on met dans une image-clé un bête movieClip qui a le défaut de jouer une animation, et l'autre défaut de jouer un son, que ce passe-t-il si ce clip est remplacé par une keyframe vide? Je n'ose croire que le son continuerait à se jouer... Si tel était le cas, il s'agit là d'un "feature" réellement rédhibitoire!

On m'objectera surement qu'une programmation "propre" permet de traiter toutes les mesures préventives ci-dessus. Mais j'ai le curieux pressentiment qu'il faudra alors ajouter 10-15% en moyenne de code supplémentaire, uniquement pour gérer l'eventuelle possibilité d'être supprimé/removed.

L'air de rien, c'est l'autonomie ou l'encapsulation des SWF qui est mise en défaut:
Si une appli.swf charge un module.swf réalisé par un tiers, et que ce tiers a laissé une seule faille dans sa gestion du remove, le module.swf sera toujours présent en mémoire.

Moi je trouve ça plutôt ennuyeux.

Et carrément fastidieux pour le codage, ainsi que les tests (mais bon, ça doit être parce que je suis paresseux ).

Je ne vois que 2 solutions:

• l'ajout d'une fonction wildDestroy() dans AS 3.1, c-à-d que tout le boulot de tracking des références soit fait par le player Flash au moment du destroy, et non plus par le développeur...
  
• l'émergence de "best practices" simples et fiables, partagées par tous les développeurs AS 3.0 de la Terre. Seule une intelligence extra-terrestre me semble en mesure de nous mettre sur la voie (si une telle intelligence existait, elle aurait d'autres dossiers autrement plus importants à traiter pour nous: écologie, politique, etc..)

Donc en conclusion: je me tate encore .