Sent from my iPhone
On Oct 30, 2007, at 11:15 AM, Michael O'Brien <[EMAIL PROTECTED]> wrote: > Totally agree that ES4 can be implemented without undue bloat. ES4 VMs > should remain small with modest growth despite the features being > considered for ES4. > > We too are creating a compliant ES4 implementation to serve embedded > devices. So our target is not so much browsers, but small embedded > devices including mobile. Typical uses are mobile widget engines and > embedded web servers. Our implementation (EJScript to add yet another > name) is dual license: open source and commercial as are our previous > embedded projects. You won't see much on our web about this yet -- > working too hard to complete our Alpha ;-), but we have both a Java > and > C VM running the majority of the ES4 language already including most > of > the big items: classes, packages, units, type annotations and have > been > using it in some commercial products already. So we are field testing > ES4 features as we go. > > Our all up target memory footprint is < 250K for a minimal script. We > are currently on target although we are missing some of the runtime > library. We have a split compile / VM design so this does not include > the compiler footprint. We have found that some of the ES4 features > are > essential for us to get such a small base footprint. The improved > typing > greatly enhances early binding and helps allows byte code sizes to be > reduced. Now if you have large programs and large object counts -- > memory will go up of course. > > I would STRONGLY urge that those who have concerns about the ES4 spec, > engage and try writing some code with ES4. The features blend well > and > the end result is a nice expressive language that keeps the old ES3 > dynamism but adds powerful constructs for safer, more scalable > programs. > It seems to wear well the more you use it. It also works well > incrementally where you can start with ES3 and selectively employ ES4 > features as you wish. > > Michael O'Brien > > > Steven Johnson wrote: >> The suggestions of bloat and instability from some corners are rather >> disingenuous when you consider that >> >> (1) at least one high-quality ES4 engine (Tamarin) will be >> available with a >> source license compatible with both open-source and commercial >> vendors, so >> the claim that it will be hard for browser vendors to implement can >> theoretically be reduced to a claim that it will be hard for >> browser vendors >> to integrate. (Sure, there may be technical or political obstacles >> to using >> a particular engine, but assuming that the ES4 spec will require >> every >> browser vendor to write their own implementation is clearly false.) >> >> (2) at least two active contributors to Tamarin (Adobe and Mozilla) >> have a >> very high vested interest in keeping code size small, as the >> success of both >> Flash Player and Firefox are predicated on acceptable download sizes. >> >> As Tom pointed out, the compiler for ES4 will definitely get more >> complex, >> but the VM is unlikely to grow significantly in size or complexity. >> >> _______________________________________________ >> Es4-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es4-discuss >> >> > _______________________________________________ > Es4-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es4-discuss _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
