Ce week-end, j'ai fait mes premiers pas en utilisant Python. J'avais évidemment entendu parler de nombreuses fois de ce langages au cours de diverses discussions et dans le domaine professionnel (notamment parce que je bosse avec Trac), mais je n'avais jamais mis les mains dans le cambouis pour voir quel tronche ça avait.

En lisant The Pragmatic Programmer, je suis tombé sur une recommendation du style "étudiez au moins un langage par an", et ça m'a motivé. Du coup, voilà. Et ben putain, j'aurais du faire ça plus tôt. C'est carrément ultime. Syntaxe simple, légère, peu capricieuse mais forçant la lisibilité, documentation bien foutue, tutos poussés vraiment intéressants, vitesse d'execution excellente, grande quantité de bibliothèques, ...

Je me réjouis vraiment d'utiliser ça dans un contexte un peu plus serieux que dans ma petite sandbox. Allez, je suis sûr qu'il va bien falloir deux ou trois moulinettes à coder dans la semaine qui arrive... Histoire de me mettre dans le bain et de passer en revue le langage rapidement, j'ai réimplémenté un algo que l'on utilise sur Dofus pour la génération des noms de personnages, et qui est accessoirement ultra-connu: les chaînes de Markov.

Z'allez voir, c'est que du bonheur.

Tout le monde aura déjà écrit un code de ce genre :

Ca marche bien. Mais il se trouve que dans mon projet, on a tendance à avoir besoin de beaucoup, beaucoup de loaders. Je me suis donc dit "Allons, Tyn, utilise donc un pool !" Ce qui marche également bien. On a un gain de plus de 1000% en utilisant un pool de Loader plutôt que d'en créer de nouveaux à chaque fois.

Mais qui dit pool dit nettoyage d'objet, et rendu dudit objet au pool après son utilisation. Hors, dans ce cas précis, j'ai un gros soucis: je ne peux pas récupérer mon objet Loader dans mon callback onIOError! C'est quand même très, très con. Ca signifie que je perds un élément de mon pool à chaque URL foireuse, ce qui est un leak inacceptable.

Voici donc un contournement foireux pour récupérer son objet Loader depuis un callback où LoaderInfo.loader n'est pas encore renseigné:

Et hop. C'est quand même bien crade. Si un gentil développeur de chez Adobe passe par ici (sait-on jamais), c'est quand même con que le Loader ne soit pas accessible depuis l'objet LoaderInfo en cas d'erreur de chargement alors qu'il est disponible avant le chargement. Allez, salut.

En AS3, on peut faire un chouette truc tel que décrit dans le billet sur les balises embed, à savoir ceci :

(Pour les détails, se référer au billet sur la métadonnée embed.)

Maintenant, imaginons que dans notre symbole "test", on aie un TextField qui se nomme "_tfFoo". Dans notre classe décrivant ce symbole, on en aura certainement besoin. Tout naturellement, je l'aurais ajouté en faisant :

Sauf qu'en fait non. Si on fait ça, le compilateur gueule :

ReferenceError: Error #1056: Impossible de créer la propriété _foo sur net.tynambule.exp.PrivateEmbed.
	at flash.display::Sprite/flash.display:Sprite::constructChildren()
	at flash.display::Sprite$iinit()
	at net.tynambule.exp::PrivateEmbed$iinit()[Y:\Code\Workspace\Exp\src\net\tynambule\exp\PrivateEmbed.as:11]
	at net.tynambule.exp::PrivateEmbedContainer$iinit()[Y:\Code\Workspace\Exp\src\net\tynambule\exp\PrivateEmbedContainer.as:12]

Pourquoi? Parce que les éléments placés sur la scène dans un symbol embed ne sont pas internal (ni private, ni protected), mais... public. Ce qui m'oblige à réécrire :

Et là, ça marche. Sauf que moi, j'aurais bien aimé que mon joli TextField ne soit pas accessible depuis n'importe où dans mon code, vu que je préfère quand l'interface est planquée dans son coin et qu'elle n'a rien à voir avec la logique.

Voili voilou, c'est pas très joli et c'est un peu prise de tête de piger pourquoi ça foire. J'me demande pourquoi Adobe a fait ça. Snif. Allez, salut.

Parfois, avec Flash, il faut savoir réinventer la roue. Par exemple, lorsque l'on veut coder un moteur d'animation qui s'intègre au sein d'un système de rendu isométrique complexe, on aimerait à la foi pouvoir disposer d'un framerate le plus élevé possible, tout en jouant les animations au framerate dans lequel elles ont été réalisées.

Pour se faire, il faut obligatoirement passer par l'indispensable case du calcul du framerate en cours. Il existe peut-être des mondes merveilleux ou la valeur que l'on a entrée dans le champ "Nombre d'images par secondes" de l'IDE Flash est tout le temps vraie, mais il ne s'agit pas du notre.

Voyons différentes approches pour calculer un framerate.

Il y a peu, le monde merveilleux de l'ActionScript 3 s'est ouvert à moi. Même si certaines choses sont un peu déroutantes, ayant parcouru un très long chemin en AS2 (raah, l'absence de constructeurs private/protected! Enfoirés de l'ECMA, laissez tomber cet héritage par prototype à la con!), certaines des nouvelles fonctionnalités tuent carrément.

Un truc qui m'avait toujours gonflé en AS2, c'est la liaison entre les assets et le code. Je codais sous Eclipse en compilant avec MTASC, et je modifiais mes assets sous Flash. Seulement, histoire de pouvoir les associer à une classe, je devais, au choix, mettre ma classe sous Flash (et me taper une compilation AS par Flash d'environs 30 minutes), ou faire une grosse méthode bourrine à coup de Object.registerClass.

C'était, avouons-le, pas super beau. Mais désormais, en AS3, les gens d'Adobe ont rajoutés des métadonnées merveilleuses qui permettent de faire ça tout seul, et bien plus encore.