http://calculist.blogspot.com/2008/08/death-of-namespaces.html
oui je pourrais repondre sur son blog mais ce serait peine perdu
dans cette bataille ES4 vs non-surtout-pas-ES4 ce serait juste
argumenté pour le plaisir d'argumenter quand on sait que ES4
est deja abandoné officiellement.
mais par contre cela peut etre constructif de lancer une discussion
sur l'utilisation des namespaces en AS3, j'ai plein d'exemples
concrets
que je trouve tres utiles et helas peu de gens mettre vraiment en
application
l'usage de ces namespaces, donc regardons quelques exemples
1. donner acces en ecriture a une propriété sans la rendre public
----
package something
{
public namespace internal;
}
----
package misc
{
import something.internal;
public class MyClass
{
private var _myprop:String;
//...
public function get myprop():String
{
return _myprop;
}
internal function set myprop( value:String ):void
{
_myprop = value;
}
}
}
----
à l'usage ca donne
----
import something.internal;
var mc:MyClass = new MyClass();
use namespace internal;
mc.myprop = "something";
----
la propriété n'est pas public mais on peut ouvrir le namespace pour
écrire dedans
ok je dis pas qu'on a besoin d'utiliser ca tous les jours mais ca peut
se reveler tres pratique
apres on pourrait me dire que si n'importe qui peut ouvrir le
namespace internal
et donc écrire dans la propriété c'est comme si la prop etait public
ce a quoi je repondrais: oui mais non :)
le fait de devoir ouvrir un namespace pour pouvoir ecrire dans une
prop ou autre
cela montre bien l'intention que c'est un usage special en dehors d'un
access public
2. activer un mode debug avec un namespace
alors là ca va etre un exemple tres particulier avec eden
le parser est assez compliqué à debugguer
mais en meme temps le code est stable et testé
donc en gros il faut 2 modes: release et debug
release pour le code mis en "release" publique
debug pour travailler dans le code avec pleins d'infos
et bien cela donne
----
package system.serializers.eden
{
//...
import system.serializers.eden.debug;
import system.serializers.eden.release;
//...
public class ECMAScript extends GenericParser
{
use namespace release;
//...
debug function debug( message:String ):void
{
trace( message );
}
release function debug( message:String ):void
{
//do nothing
}
protected function trace( message:String ):void
{
console.writeLine( message );
}
//...
public function isDigitNumber( num:String ):Boolean
{
debug( "isDigitNumber( \""+num+"\" )" );
var numarr:Array = num.split( "" );
//...
}
//...
}
}
----
le but n'etait pas de pouvoir changer un mode "debug" dynamiquement
mais de pouvoir changer le comportement de la class a la compilation
et pour ca l'usage des namespaces est parfait
avec
use namespace debug;
la fonction debug est redirigée sur un "trace"
et avec
use namespace release;
la fonction part dans le vide
alors oui il y a des appels de cette fonction debug()
inutile dans le code de release, mais en fait cela crée
moins d'inference que si qlqpart il y avait un
if( debug ) ...
de plus le fait qu'on soit forcé de changer ce paramettre
avant compilation cela permet d'empecher le mode debug
d'etre activé qd le code est distribué en SWC
3. namespace dynamiques
normalement un namespace doit se traiter comme une constante
mais il y a moyen de rendre la section du namespace dynamique
----
package test
{
public namespace option1;
}
----
package test
{
public namespace option2;
}
----
package test
{
public class MyClass
{
public var mode:Namespace = option1;
public function MyClass()
{
}
option1 function test():void
{
trace( "hello world" );
}
option2 function test():void
{
trace( "bonjour le monde" );
}
public function test():void
{
mode::test();
}
}
}
----
à l'usage
----
package
{
import flash.display.Sprite;
import test.MyClass;
import test.option1;
import test.option2;
public class dynamicNamespace extends Sprite
{
public function dynamicNamespace()
{
var mc:MyClass = new MyClass();
mc.test();
mc.mode = option2;
mc.test();
}
}
}
----
output:
hello world
bonjour le monde
ici l'utilité est de pouvoir garder la meme signature de methodes
test()
mais de pouvoir changer dynamiquement son implementation
l'utilité ?
alors comparons avec une implemenation d'interface
imaginons que MyClass est une interface qui definit test()
et qu'il y a 2 implementation MyClassOption1 et MyClassOption2
ca nous donnerait à l'usage
var mc:MyClass = new MyClassOption1();
mc.test();
puis
mc = new MyClassOption2()
mc.test()
ah oui bah oui il faut reinstancier
donc l'utilité de pouvoir switcher dynamiquement d'un namespace a un
autre
c'est de pouvoir garder l'instance et son state (et meme de partager
les states)
mais en meme temps de changer l'implemenation
plutot puissant :)
pensez un API publique pour sauver des données qlq part
et pouvoir switcher d'une database à un web service à un fichier text
sur le disque
bref, je suis plutot content au contraire que les namespaces existent
en AS3
et ne seront donc pas virés dans le futur :)
zwetan
--~--~---------~--~----~------------~-------~--~----~
Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de
Google Groupes.
Pour transmettre des messages à ce groupe, envoyez un e-mail à
l'adresse [email protected]
Pour résilier votre abonnement à ce groupe, envoyez un e-mail à
l'adresse [EMAIL PROTECTED]
Pour afficher d'autres options, visitez ce groupe à l'adresse
http://groups.google.com/group/FCNG?hl=fr
-~----------~----~----~----~------~----~------~--~---
