Armetiz

public function fooLoop () : void
{
   //Pre traitement
   fooLoop ();
   //Post traitement
}

Voici le corps d’une fonction récursive.

Lorsque la pile est pleine, une jolie erreur du type StackOverFlowError est déclenchée.

Ce qui est intéressant de voir, c’est le comportement du Player et des navigateurs lorsque l’on traite cette erreur pour relancer la fonction récursive.

Voici le code utilisé :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" 
	layout="absolute">
	<mx:Script>
		<![CDATA[
			private function hack () : void
			{
				hack ();
			}
 
			private function click () : void
			{
				try
				{
					hack ();
				}
				catch (e: Error)
				{
					click();
				}
			}
		]]>
	</mx:Script>
	<mx:Button click="click ()" label="Nuked !" />
</mx:Application>

Avec Windows, en utilisant IE le navigateur monte en charge en utilisant la mémoire. Ce qui a pour conséquence logique de remplir le fichier d’échange. Une fois que la mémoire disponible est sèche, un mécanisme que je n’explique pas libère de la mémoire et le script continu son exécution.

Contrairement à Firefox qui après 400Mo d’utilisation mémoire, se positionne en « Ne réponds pas… » et se freeze de lui même.

Si vous voulez voir ce que cela donne, voici l’application.
Pensez à surveiller l’utilisation de votre mémoire

L’interet

Outre le fait de pouvoir faire joujou, ce script peut-être intéressant pour réaliser des traitements récursifs qui sont justement trop importants.
En, effet, vous pouvez le combiner à une variable statique pour continuer le traitement lorsque l’erreur de débordement est déclenchée.

Comment restreindre l’instanciation d’une classe à une autre classe.

Voici une idée complètement « crazy » au quelle je vais apporter une solution à travers ce billet.
Nous allons utiliser un principe connu par de nombreux framework Web qui permet d’assurer la validité d’un formulaire: Le jeton !

L’intérêt étant de combiner cela avec le pattern Factory.

public class Master
{
	private static var _jeton	: Number	= -1;
 
	public function Master()
	{
	}
 
	public static function createSlave () : Slave
	{
		var _tmpSlave	: Slave;
 
		_jeton		= Math.random() * 500;
		_tmpSlave	= new Slave (_jeton);
		_jeton		= -1;
 
		return _tmpSlave;			
	}
 
	public static function get jeton () : Number
	{
		return _jeton;
	}
}

public class Slave
{
	public function Slave(_pJeton : Number = 0) : void
	{
		if (Master.jeton !== _pJeton && Master.jeton !== -1)
			throw new Error ("Instanciation obligatoire par Master.createSlave");
	}
}

new Slave (); //throw Error
Master.createSlave (); //Retourne un objet du type Slave

Les conventions de nommage font parties de la vie d’un développeur qui souhaite faire du bon boulot.
En effet, cela permet une meilleur compréhension visuelle. Ce qui est pratique pour détecter certains problèmes évidents.

Bref, la convention de nommage concernant les classes est celle-ci :

• 1ère lettre en majuscule
• Mélange de minuscule, majuscule avec la première lettre de chaque mot en majuscule
• Donner des noms simples et descriptifs
• Éviter les acronymes : hormis ceux commum (XML, URL, HTML, …)

Analyse du contexte Flash

var _monText : String = "Hello world";
var _monNombre : int = 42;
var _monGrandNombre : int = int.MAX_VALUE;

En Flash, il existe deux types int et uint tout deux primitifs comme String ou Number. Ces types ont deux constantes de classe (MAX_VALUE, et MIN_VALUE).

Il s’agit donc de Classes, alors pourquoi la convention de nommage n’a pas été respectée ?

Après une recherche – très rapide grâce aux membres de mediabox – il en ressort que int et uint appartient à Number.

Si on analyse le code ci-dessous, on peut se rendre compte que le constructeur d’une variable de type int ou uint est Number.

var n_num: Number = 12.3;
trace(n_num["constructor"]); // [class Number]
 
var n_int: int = 12;
trace(n_int["constructor"]); // [class Number]
 
var n_uint: uint = 12;
trace(n_uint["constructor"]); // [class Number]
 
trace(n_num["constructor"] == n_int["constructor"]); // true
trace (typeof (n_num) + " " + typeof (n_int) + " " + typeof (n_uint)); //number number number

Grâce à cette démonstration par le code, nous pouvons constater que Flash respect bien la convention de nommage sur les classes, car int et uint ne sont que de « simples » appels à Number.

Maintenant, QUID de la gestion mémoire ?

PS: Autre blog, autre temps, troyworks s’est posé la même question sous une autre forme. Assez perturbant tout cela.