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.

En nos temps où l'orienté-objet est roi, un schéma de fonctionnement revient régulièrement :

Un objet dont chaque instance correspond à une ligne en base. On charge les données lors de l'initialisation de l'objet (dans son constructeur), puis on les sauvegardes lorsque l'on a fini de les modifier.

La problématique est la suivante : mais quand a-t-on fini de les modifier? Dans 99% des cas, "ça dépend". Les méthodes pour implémenter cette notion sont légions: une méthode genre save que l'on appelle "à la fin", une sauvegarde systématique à chaque modification, et la rationnelle mais risquée sauvegarde dans le destructeur de l'objet.

Cette dernière méthode semble la plus intéressante, puisqu'elle défini avec une presque certitude la notion de "fin" de modifications. Toutefois, dans notre contexte orienté objet, il y a de fortes chances que l'on utilise un objet pour se connecter à la base de donnée. Et cet objet fermera probablement sa connexion dans le destructeur. Et comment savoir que la base est encore connectée lors de l'exécution du destructeur de notre objet de données? C'est le drame.