Es4-discuss Digest, Vol 8, Issue 44
liorean at gmail.com
Tue Oct 30 18:14:51 PDT 2007
On 31/10/2007, Ric Johnson <Cedric at opendomain.org> wrote:
> I still am missing something. If someone could somehow prove that ES4 is
> flawed, do we have actually have a chance to fix it before it is burned
> over my childhood memories? How do we do that? Do I need to draw up a
> diagram comparing similar systems and show failure rates mathematically
> and then mail it to Al Gore?
There's features broken and there's language broken. I'd argue that
the ES3 regex model is broken, that ES4 could and should fix it*, and
that it won't hurt live code to do so but will help making regex in ES
make sense. But on the other hand, ES3 has an unambiguous spec on this
point, and Opera and Mozilla both seem to implement it as specified.
Not fixing it right now would not really hurt the language, the
language isn't broken by this feature being broken, except for making
it harder to fix in the future (and possibly harder to add new
features such as conditionals and lookbehinds). So language not
broken, only less useful that it could be.
I've yet to see any single argument with technical merit that the
language is broken - I've seen broken features, mostly broken since
ES3 that can't be fixed without breaking backwards compatibility, but
nothing that breaks the language. The argument about ES4 additions
size > ES3 size is the only one that seems to have any merit
whatsoever, and that only in the way of being somewhat limiting on
limited power devices such as mobile phones, where the compiler and vm
size must be kept low.
> To put another face on it, it seems to me we are being unfair. If Opera
> put in a new feature in their browser, I assume most people would just
> believe it was their business. BUT if Microsoft decides to put a direct
> would ALL cry foul. Is ES4 the new OOXML? In effect, some major
> players are getting together to force a standard that the others do not
> agree on. Then again, if Microsoft simply did not implement Javscript2,
> would the other vendors be happy?
I think there'd be considerably more happiness if Microsoft provided a
.NET based ECMAScript 4 compliant JScript version in IE8/9, whether
based on JScript.NET or as a DLR runtime, than if they didn't provide
an ECMAScript 4 engine at all by IE9. Even a COM/IDispatchEx version
would be welcomed over not having an ECMAScript 4 engine at all. Sure,
we have an effort to get a Tamarin version to hook into IE by
COM/IDispatchEx. Who will distribute it (pretty sure Microsoft will
not), can it reach enough users to matter? Can the distributor be
trusted in corporate environments? Can it be compatible enough with
legacy JScript to be used as an all-out replacement?
Actually, I'd be more comfortable with an ECMAScript 4 engine based on
.NET in IE than I would be with even a Microsoft backed Tamarin
engine. I think the more interoperable implementations on different
virtual machines the better, and ECMAScript 4 on .NET opens up for
single language client and server side code, which I think many
developers would like. (Most of them just don't want the single
* I've had the argument before, the idea is simply summed up as:
- Backreferences to capturing submatches that have not participated or
that failed to match should fail. (In ES3 these succeed at matching
the empty string.)
- A capturing submatch should be reset only next time it participates
in a match. (Instead of each time the containing group is repeated, as
- Backreferences to repeated submatches must always reference the
value of the submatch last time it participated and matched.
(IE/JScript uses the first match always, even if there are later
One example trick that doesn't work in ES3 but works in other regex
implementations is this pattern used for conditionals:
However, this fails in the ES3 model since all of \1, \2 and \3 will
always match the empty string, instead of either both \1 and \2
failing or \3 failing.
David "liorean" Andersson
More information about the Es4-discuss