le pourquoi de solo
zwetan
j'ai annoncé l'autre jour le projet solo et je vais essayer ici de
donner plus de details sur le pourquoi ce serait bien que ce projet
existe.
Il y a a peu pres 1 an dans une discussion sur le newsgroup
netscape.public.mozilla.jseng
j'ai eut cette réponse de Brendan Eich (createur de JavaScript).
http://groups.google.com/group/netscape.public.mozilla.jseng/msg/6f72e70880311ce1
------------------------------------------
...
That's what I meant in my other post about "standard library mechanism"
-- it's fine to embed JS (JScript, whatever) in a Java, .NET, or other
world and use that world's standard packages. But people writing
portable JS, esp. for a common interoperable platform like the browser
or Linux, want a set of standard packages that are named and work the
same everywhere.
JS has lacked this for too long, being in the browser, or in the shadow
of a larger system of reusable packages such as a JVM. Nothing wrong
with Rhino, mind you -- but something's missing from JS-the-language.
/be
------------------------------------------
trad FR:
C'est ce que je disais dans mon autre post a propos d'un "mecanisme de
librairie standard"
-- c'est bien d'inserer JS (JScript, n'importe) dans un monde Java,
.NET, ou autre
et utiliser les packages standards de ce monde.
Mais les gens ecrivant du JS portable, specialement pour des platformes
d'interoperation communes comme le navigateur ou Linux, veullent un set
de packages standards qui sont nommés de la meme maniere et marchent
partout de la meme maniere.
JS a manqué de cela pendant trop longtemps, étant dans le navigateur,
ou dans l'ombre de plus grand systemes ayant des packages reutilisable
comme la JVM.
Attention, il n'y a rien de mal avec Rhino -- mais il y a quelquechose
qui manque dans JS-le-langage.
------------------------------------------
Et là, ca a fait "tilt", il a su exprimé en quelques lignes et
simplement un probleme qui existait depuis des années, meme probleme
qui m'a poussé a implémenter core2, mais que je ne pouvais pas
vraiment expliqué aussi simplement.
Avec ce qui va arriver (flex2 et AS3) nous sommes a une période
charniere,
c-a-d une évolution tres attendue (trop longtemps attendue meme) d'un
langage: ECMAScript.
Que vous regardiez dans le monde Flash ou dans le monde Ajax vous
pouvez voir que tout le monde y va de son framework pour faire ci, pour
faire ca, mais que si on regarde tous les projets dans leur globalité
personne ne fait cela de maniere "standard", a part quelques cas trop
rare il est tres difficile de combiner plusieurs librairies et/ou
frameworks.
Ceci est causé par un standard (ECMA-262 3eme edition) qui a été mis
un peu a toutes les sauces sans vraiment évolué (oui meme avec AS2).
Sauf que là avec AS3 (1ere implémentation de ECMAScript 4) tout ce
qui manquait est enfin arrivé, mais il y a toujours ce manque de
librairies standards.
C-a-d que meme si le langage a évolué et nous permet meme de
programmer des sockets, du binaires etc. il lui manque toujours un
framework applicatif comme on pourrait en trouver un en Java , .NET et
autre.
En bref, on a le potentiel, mais pas l'implémentation.
Et c'est ce que je propose de résoudre avec solo.
En résumé, implémenter solo pour AS3, ce serait faire le meme boulot
que celui de mono en portant .NET pour pouvoir l'utiliser sous Linux et
toutes les autres plateformes,
sauf que l'on est quand meme dans une configuration differente: .NET
pour l'instant est surtout utilisé coté serveur et/ou appli desktop
car la VM .NET est tres faiblement distribuée sur les clients (normal
elle fait ~20Mo), et pour la VM Flash 9 on ne pourra pas l'utilisé
coté serveur mais principalement coté client web et voire peut-etre
plus tard pour des applis desktop, mais avec l'avantage d'etre d'office
cross-platform (en fonction de où est porté le player flash).
AS3 pour l'instant va etre le langage qui va nous permettre de compiler
(via flex2)
des applications clients visant le player flash 9.0 (ex 8.5), puis par
la suite viendra
aussi la compilation avec le Flash IDE 9.0, et puis apres on pourra
peut-etre meme utiliser AS3 pour compiler des applis desktop
fonctionnant avec Apollo.
Mais ca ira plus loin encore, les prochaines moutures de firefox (la
v3.0 je crois) auront JavaScript 2.0 qui lui aussi sera basé sur
ECMAScript 4 et qui donc normalement devrait pouvoir reutiliser des
librairies ecrites en AS3 (trop tot pour le savoir, mais scenario
possible).
Donc le but de solo ce serait d'implémenter le framework .NET (pas
forcément tout, pas forcément exactement de la meme maniere) pour
disposer d'un framework applicatif coté client qui manque cruelement
depuis des années.
Mais pourquoi faire cela ?
Prenez quelqu'un qui veut développer une librairie pour .NET ou meme
un framework,
des le depart il peut se baser sur le framework .NET, il a deja une
grosse base de code et de fonctionnalités qui lui simplifient
grandement la vie.
Pour un meme projet en AS3, sans framework applicatif, il faudra creer
ces briques de base, mais le pire c'est que pour 2 projets differents
en AS3 bcp de ces briques seront dupliquées car voila il n'y a pas un
framework applicatif commun et standard.
Le fait d'implementer solo pour obtenir ce framework applicatif en
s'inspirant de mono et du framework .NET permettrait d'eviter ces
duplications de fonctionnalités de base.
Je vais prendre un exemple basique, le namespace System.IO du framework
.NET
et les classes File, Directory et Path.
Avec AS3, meme si on a FileReference, FileFilter, etc. il y aura
surement des cas où les fonctionnalités qui existent dans les classes
File, Directory et Path seront utiles,
par exemple: un explorer de fichier remote ou autre gestion de
fichiers.
Bref, meme si Adobe fournit une base de packages, classes etc.,
je pense que cette base n'est pas suffisante car trop simple ou trop
concentré sur le monde Adobe/Flash.
Le but n'est pas de trop compliquer les choses ni de faire une usine a
gaz qui fait tout,
mais juste de prendre en exemple l'esprit du projet mono et de suivre
le guide de l'architecture du framework .NET pour ensuite calquer cela
en AS3.
Ce projet est énorme, generera de longues discussions sur les choix a
faire, quoi implementer en 1er, comment l'implementer,
dupliquer/heriter ou pas ce qui existe deja en AS3, etc.
mais amha ca faut le coup pour toutes les fonctionnalités qui
pourraient en résulter.
zwetan
shaoken
Cette idée, bien que très ambiteuse, est pleine de potentiel et me
tente énormément.
Comme demandé dans ton mail, tu peux compter sur ma présence parmis
les devs. Si tu la juges utile bien entendu ;)
++ :)
Philippe
Par contre, il y a des différences assez importantes entre les 2
mondes. Comment peuvent-elles être *efficacement* surmontées tout en
restant compatibles au maximum ?
zwetan
:)
je n'ai pas vraiment a juger qui sera utile ou pas,
mais bon il y aura qd meme quelques regles d'organisation de projets a
respecter comme utiliser subversion, publier des unit tests en // des
class, utiliser un bug tracker, etc.
mais sommes toutes des choses normales vue l'ampleur du projet.
Meme si le projet est ambitieux (vu la grosseur du portage en fait)
je pense qu'il est possible que chaque dev gere la responssabilité de
son et/ou ses package(s), que un dev A fasse le code review du code
d'un dev B et vise versa,
et donc oui comme le dit philippe de "découpé" le developpement meme
si ca reste un travail d'equipe.
Et ne pas oublier que c'est aussi un projet pour apprendre/approfondir
AS3,
meme si on peut reutiliser nos experiences diverses dans d'autres
langages,
AS3 reste un langage tres jeune que en fait personne ne maitrise
completement,
se mettre sur des problemes communs a plusieurs ca peut booster les
connaissances de tout le monde.
Pour ce qui est des différences, je pense que j'insiterais toujours
sur le fait que l'on programme en ECMAScript et qu'il faudra donc tirer
avantage de cela, cad ne pas chercher a tout prix a copier C# le
langage (ni meme Java) mais juste copier les fonctionnalités des
package meme si sous le capot l'implémentation est tres différente.
De plus il y aura pas mal de choses qui ne vaudront pas le coup d'etre
porté ou qui simplement de part la différence d'environnement ne
pourront pas etre porté,
par exemple la gestion de sécurité d'execution du code en .NET
(AppDomain, CodeAccessPermission, etc.), voir ce qui s'est fait avec
mono, certains packages ont ete completement revus a la sauce mono,
tout n'est pas ideal en .NET faut pas rever :).
Pour moi etre compatible .NET n'est pas vraiment la priorité,
le but principal je pense est plus de fournir un framework qui n'existe
pas au depart,
et tant qu'a faire s'inpirer du travail de gens plus experimentés et
plus nombreux,
mais limite on pourrait en meme temps s'inspirer aussi du framework
Java.
Mais attention si on s'inspire de tous les cotés on risque de un peu
tout mélanger,
ici le choix de s'inspirer principalement du framework .NET et mono
c'est juste que etant arrivés les derniers ils sont un peu mieux
fait/penser que le framework Java,
meme si ce jugement reste relatif.
Il faut voir sa comme une base de depart qui aura surement sa propre
evolution par la suite.