[...]
> En parlant
> d'as3-coreutils, au départ je pensais le contribuer à maashaack mais
> n'ayant pas eu de réponse à une demande de contribution, bah j'ai
> simplement crée un projet pour partager ce que j'estimais être
> important. Je trouve dommage de dédoubler comme ça les efforts.
>
oui je vois ca dans le google form du 01/10
mais ce qui me tue, pourquoi tu as pas simplement ouvert un thread
ici ???
> Bref.
>
> > mais en soit si on regarde dans toutes les libs et framework pour AS3,
> > il y a pas un seul qui essaye de rassembler tout d'une maniere
> > standard et logique
> > (enfin si y a maashaack mais bon on est loin de tout supporter)
>
> Standard et logique, à l'appréciation de son/ses créateurs ;)
>
dans maashaack il y a différents principes
en general on ajoute pas tout et rien juste pour le plaisir de grossir
le framework,
la plupart des classes sont là parce qu'elles sont utilisées dans
plusieur projets concrets
et le princip le plsu important est celui de concensus,
en gros pour que ca ne parte pas dans 50 directions, tout le monde
doit etre
plus ou moins d'accord
ex: "hey transformons maashaack en framework MVC!!!"
là ca va etre "non" vu que c'est pas le but du projet de fournir de
l'architecture et/ou micro-architecture
ca peut s'envisager en addon, a voir, mais pas la priorité
par contre
"toutes les libs de crypto pour AS3 c'estde la grosse merdasse,
j'aimerais bosser sur system.cryptography.*"
là oui on peut discuter
ca tombe completement dans la logique de standardisé quelque chose qui
peut etre reutilisable
pour l'instant le principal problem dans maashaack c'est le temps
(comme bcp de projets open source)
on est dans une phase de restructure de la build et de documentation
pour justement que d'autres personnes puissent contribuer plus
facilement
pour ce qui est de "à l'appréciation de son/ses créateurs ;)"
autant il y a un but global assez clair "faire un framework
applicatif"
ca ne veut pas dire que tous contributeur doit absoluement penser de
la meme maniere
rien que entre eka et moi, il y a des différences
par ex, perso j'essaye de toujours favoriser la compatibilité tamarin
ou d'avoir des tres petites classes dans core.*
et eka trouve bcp d'inspiration dans la fondation apache et va pousser
des choses plus loin pour les events, les data, etc.
et donc on est pas toujours d'accord sur tout
mais ca n'empeche pas que le framework avance dans la meme direction
c'est CA la partie logique et standard
besoin A:
- j ai besoin d'une fonctionalité bien précise, comme une lib
- je ne veux pas le reste du framework, que ce soit pour le poids ou
autre raison
- pas grave si j'ai l essentiel et qu'il y ait des limitations
etc.
=> utiliser core.version, core.uri, etc.
besoin B:
- je veux toutes les options possibles organisées de maniere logique
(cad comme un framework applicatif)
- le poids n'est pas un probleme (euh utiliser system.* en general ca
n'ajoute que quelques 10aines de KB... c'est pas Flex hein)
- je veux plus d'options encore
etc.
=> utiliser system.Version, system.URI, etc.
-> plus d'option: utiliser system.eden pour deserialiser
version.txt dans un object version
-> utiliser system.events.* pour etre notifier quand ces options
changent
etc.
le truc c'est que tout ca devrait etre bien mieux documenter dans le
wiki
et pas eut trop le temps ces long dernier mois
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
-~----------~----~----~----~------~----~------~--~---
