info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Can we remove E4X support?
152 views
Skip to first unread message
Tom Schuster
Jan 3, 2012, 2:27:41 PM1/3/12
to dev-tech-...@lists.mozilla.org
We don't really maintain E4X anymore besides bug fixes, and in the
overall scheme of things it even slows down development.
a) It makes parsing a lot more difficult as it needs to be.
b) Some features like objects as properties don't really fit into the
modern design anymore.
c) It's dead on the internet, you need to opt-in, and it's Mozilla only.
I know there are supposed to be some people using this, and I don't
really feel comfortable with the idea of dropping them. I have no idea
what kind of feature are used from E4X, but maybe some stuff can be
replaced by an xml parser.
I have a patch ready that removes basic support, but there are
probably a lot more code that could be simplified or removed without
E4X.
Tom
overall scheme of things it even slows down development.
a) It makes parsing a lot more difficult as it needs to be.
b) Some features like objects as properties don't really fit into the
modern design anymore.
c) It's dead on the internet, you need to opt-in, and it's Mozilla only.
I know there are supposed to be some people using this, and I don't
really feel comfortable with the idea of dropping them. I have no idea
what kind of feature are used from E4X, but maybe some stuff can be
replaced by an xml parser.
I have a patch ready that removes basic support, but there are
probably a lot more code that could be simplified or removed without
E4X.
Tom
Wes Garland
Jan 3, 2012, 2:34:09 PM1/3/12
to Tom Schuster, dev-tech-...@lists.mozilla.org
Please keep "for each". I can't see it being expensive, and it's handy as
hell.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
hell.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Ash Berlin
Jan 3, 2012, 2:41:25 PM1/3/12
to dev-tech-...@lists.mozilla.org
On 3 Jan 2012, at 19:34, Wes Garland wrote:
> Please keep "for each". I can't see it being expensive, and it's handy as
> hell.
>
> Wes
-ash
Tom Schuster
Jan 3, 2012, 3:18:43 PM1/3/12
to Ash Berlin, dev-tech-...@lists.mozilla.org
Funny, in fact didn't realize that for each is a E4X feature, because
this doesn't seem to be mentioned anywhere in the code. Keeping it is
no problem from my point of view.
Tom
> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
this doesn't seem to be mentioned anywhere in the code. Keeping it is
no problem from my point of view.
Tom
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
Tei
Jan 4, 2012, 4:28:40 AM1/4/12
to dev-tech-...@lists.mozilla.org
Here is me, a random person from the internet.
I am posting this for the benefict of people searching E4X in google
and finding this thread.
A lot of the things [probably not all] that made E4X desirable are
doable with the tricks that support "client side templating", stuff
like this:
http://ejohn.org/blog/javascript-micro-templating/
Small templates, embeded on the document, invisible to the user
inside <script language="funny name"> tags.
*removes hat*
Bye E4X, I Hardly Knew Ye.
--
--
ℱin del ℳensaje.
I am posting this for the benefict of people searching E4X in google
and finding this thread.
A lot of the things [probably not all] that made E4X desirable are
doable with the tricks that support "client side templating", stuff
like this:
http://ejohn.org/blog/javascript-micro-templating/
Small templates, embeded on the document, invisible to the user
inside <script language="funny name"> tags.
*removes hat*
Bye E4X, I Hardly Knew Ye.
--
ℱin del ℳensaje.
Mark Constable
Jan 4, 2012, 6:59:27 AM1/4/12
to dev-tech-...@lists.mozilla.org
On 04/01/12 19:28, Tei wrote:
> A lot of the things [probably not all] that made E4X desirable
> are doable with the tricks that support "client side templating",
> stuff like this: http://ejohn.org/blog/javascript-micro-templating/
You've got to be joking. Nothing beats...
> A lot of the things [probably not all] that made E4X desirable
> are doable with the tricks that support "client side templating",
> stuff like this: http://ejohn.org/blog/javascript-micro-templating/
var title = "E4X Template", content = "I love e4x templating"
var body =
<body>
<h1>{title}</h1>
<p>{content}</p>
</body>;
print(<html>{body}</html>)
Tei
Jan 4, 2012, 8:03:20 AM1/4/12
to dev-tech-...@lists.mozilla.org
For most people this will be enough:
var body =
"<body>
<h1>{title}</h1>
<p>{content}</p>
</body>";
print( someTemplateEngine(body,json).html() );
I understand that the point of E4X was syntax sugar to make the syntax
more clear, and mix node tags with variables freely and withouth
hassle. You can't get that with a js-template-engine.
Mark Constable
Jan 4, 2012, 8:17:18 AM1/4/12
to dev-tech-...@lists.mozilla.org
On 04/01/12 23:03, Tei wrote:
> For most people this will be enough:
>
> var body =
> "<body>
> <h1>{title}</h1>
> <p>{content}</p>
> </body>";
I think you meant...
> For most people this will be enough:
>
> var body =
> "<body>
> <h1>{title}</h1>
> <p>{content}</p>
> </body>";
var body = "\
<body>\n\
<h1>{title}</h1>\n\
<p>{content}</p>\n\
</body>\n\
";
> print( someTemplateEngine(body,json).html() );
Why use someone else's idea of someTemplateEngine() when a universal
E4X engine is built in (other than client side cross browser support).
Hands down, nothing beats E4X for HTML templating.
Peter Wilson
Jan 4, 2012, 8:22:27 AM1/4/12
to Tom Schuster, dev-tech-...@lists.mozilla.org
On 03/01/2012 19:27, Tom Schuster wrote:
> We don't really maintain E4X anymore besides bug fixes, and in the
> overall scheme of things it even slows down development.
>
> a) It makes parsing a lot more difficult as it needs to be.
But it's done
> We don't really maintain E4X anymore besides bug fixes, and in the
> overall scheme of things it even slows down development.
>
> a) It makes parsing a lot more difficult as it needs to be.
> b) Some features like objects as properties don't really fit into the
> modern design anymore.
Modern design of what? Spidermonkey? Javascript?
> modern design anymore.
> c) It's dead on the internet, you need to opt-in, and it's Mozilla only.
May be dead in the browser
>
> I know there are supposed to be some people using this, and I don't
> really feel comfortable with the idea of dropping them. I have no idea
> what kind of feature are used from E4X, but maybe some stuff can be
> replaced by an xml parser.
Have one of those. It would have been good if E4X had the appropriate hooks to
> I know there are supposed to be some people using this, and I don't
> really feel comfortable with the idea of dropping them. I have no idea
> what kind of feature are used from E4X, but maybe some stuff can be
> replaced by an xml parser.
interface with that but it still has uses.
>
> I have a patch ready that removes basic support, but there are
> probably a lot more code that could be simplified or removed without
> E4X.
>
> Tom
I use E4X in a number of places server side to deal with web-services. If I'd
> I have a patch ready that removes basic support, but there are
> probably a lot more code that could be simplified or removed without
> E4X.
>
> Tom
had the time to go back and re-engineer various other areas of my code I'd be
using it more.
Please bear in mind that those using SpiderMonkey server-side don't generally
have the same issues of avoiding all new language constructs until every browser
has support and so you'll likely find many early adopters in this audience.
There isn't a 3 year lag between the first implementations and the first use!
Best regards
Peter Wilson
--
Whitebeam Architect (http://www.whitebeam.org)
Apache - Javascript - XML - Postgres
Peter Wilson
Jan 4, 2012, 8:22:27 AM1/4/12
to Tom Schuster, dev-tech-...@lists.mozilla.org
On 03/01/2012 19:27, Tom Schuster wrote:
> We don't really maintain E4X anymore besides bug fixes, and in the
> overall scheme of things it even slows down development.
>
> a) It makes parsing a lot more difficult as it needs to be.
But it's done
> overall scheme of things it even slows down development.
>
> a) It makes parsing a lot more difficult as it needs to be.
> b) Some features like objects as properties don't really fit into the
> modern design anymore.
> modern design anymore.
Modern design of what? Spidermonkey? Javascript?
> c) It's dead on the internet, you need to opt-in, and it's Mozilla only.
May be dead in the browser
>
>
> I know there are supposed to be some people using this, and I don't
> really feel comfortable with the idea of dropping them. I have no idea
> what kind of feature are used from E4X, but maybe some stuff can be
> replaced by an xml parser.
> really feel comfortable with the idea of dropping them. I have no idea
> what kind of feature are used from E4X, but maybe some stuff can be
> replaced by an xml parser.
Have one of those. It would have been good if E4X had the appropriate hooks to
interface with that but it still has uses.
>
interface with that but it still has uses.
>
> I have a patch ready that removes basic support, but there are
> probably a lot more code that could be simplified or removed without
> E4X.
>
> Tom
> probably a lot more code that could be simplified or removed without
> E4X.
>
> Tom
Peter Wilson
Jan 4, 2012, 8:59:32 AM1/4/12
to Mark Constable, dev-tech-...@lists.mozilla.org
var body =
<body>
<h1>{title}</h1>
<p>{content}</p>
</body>;
gives you a much better chance that what you're holding is valid XML (can't
<body>
<h1>{title}</h1>
<p>{content}</p>
</body>;
remember offhand whether the substituted value of {title} is validated).
So
var body =
<body>
<h1>{title}<h1>
<p>{content}</p>
</body>;
Gives you an error when you run the script.
Using the text equivalent gives no such error and given the forgiving nature of
many browsers you may never notice.
Exactly the problem with generating web-pages by just doing lots of 'prints'
with no server-side guarantee that what you're generating is valid.
Peter Wilson
Jan 4, 2012, 8:59:32 AM1/4/12
to Mark Constable, dev-tech-...@lists.mozilla.org
On 04/01/2012 13:17, Mark Constable wrote:
Another valid argument for E4X is that:
var body =
<body>
<h1>{title}</h1>
<p>{content}</p>
</body>;
<body>
<h1>{title}</h1>
<p>{content}</p>
</body>;
gives you a much better chance that what you're holding is valid XML (can't
remember offhand whether the substituted value of {title} is validated).
So
var body =
remember offhand whether the substituted value of {title} is validated).
So
<body>
Tei
Jan 4, 2012, 9:18:12 AM1/4/12
to dev-tech-...@lists.mozilla.org
On 4 January 2012 14:17, Mark Constable <ma...@renta.net> wrote:
> On 04/01/12 23:03, Tei wrote:
>>
>> For most people this will be enough:
>>
>> var body =
>> "<body>
>> <h1>{title}</h1>
>> <p>{content}</p>
>> </body>";
>
>
> I think you meant...
>
> var body = "\
> <body>\n\
> <h1>{title}</h1>\n\
> <p>{content}</p>\n\
> </body>\n\
> ";
oops, you where right. I was using a undocumented feature that violate specs
> On 04/01/12 23:03, Tei wrote:
>>
>> For most people this will be enough:
>>
>> var body =
>> "<body>
>> <h1>{title}</h1>
>> <p>{content}</p>
>> </body>";
>
>
> I think you meant...
>
> var body = "\
> <body>\n\
> <h1>{title}</h1>\n\
> <p>{content}</p>\n\
> </body>\n\
> ";
"A 'LineTerminator' character cannot appear in a string literal, even
if preceded by a backslash" "
hope nobody notices <.< ...hum... >.>
Mark Constable
Jan 4, 2012, 9:29:27 AM1/4/12
to dev-tech-...@lists.mozilla.org
On 04/01/12 23:59, Peter Wilson wrote:
> Another valid argument for E4X is that:
> var body =
> <body>
> <h1>{title}</h1>
> <p>{content}</p>
> </body>;
>
> gives you a much better chance that what you're holding is valid XML
> (can't remember offhand whether the substituted value of {title} is
> validated).
By the time it gets to something like this the whole page is valid...
> Another valid argument for E4X is that:
> var body =
> <body>
> <h1>{title}</h1>
> <p>{content}</p>
> </body>;
>
> gives you a much better chance that what you're holding is valid XML
> (can't remember offhand whether the substituted value of {title} is
> validated).
print(<html>{body||''}</html>)
<input type="hidden" name="userid" value={typeof uid == 'number' ? uid : 0}/>
and lists work like...
function actionbar(actions) {
actions = actions || ['Cancel','Save'];
var a = <></>;
for(var i in actions) a += <input type="submit" name="a" value={actions[i]}/>;
return <li>{a}</li>;
}
All built in for free.
Igor Bukanov
Jan 4, 2012, 10:18:29 AM1/4/12
to Peter Wilson, Tom Schuster, dev-tech-...@lists.mozilla.org
On 4 January 2012 14:22, Peter Wilson <pe...@yellowhawk.co.uk> wrote:
> I use E4X in a number of places server side to deal with web-services. If
> I'd had the time to go back and re-engineer various other areas of my code
> I'd be using it more.
Do you use it only as a template engine to construct XML or do you use
> I use E4X in a number of places server side to deal with web-services. If
> I'd had the time to go back and re-engineer various other areas of my code
> I'd be using it more.
it also to extract information from XML and/or transform it? Most
complications with E4X comes from the latter, the support for XML
literals affects only the parser, the runtime support for it is
trivial. On the other hand XML queries and mutators requires a lot of
complex code to write and maintain. But if that is not used in custom
embeddings of SpiderMonkey, then we can consider to remove just that
part.
Peter Wilson
Jan 4, 2012, 10:28:27 AM1/4/12
to
pull information from an input tree.
I think I've only used the ability to extract information from a tree on an
experimental basis. In practice I have an XML parser and XPath tools available
with which I'm more familiar so I tend to use those to deconstruct incoming
messages.
If I hadn't had my own tools then E4X would have been an ideal tool for
extracting information so it would be good to hear from other embedders.
Pete
Mark Constable
Jan 4, 2012, 10:40:51 AM1/4/12
to dev-tech-...@lists.mozilla.org
On 05/01/12 01:18, Igor Bukanov wrote:
> Do you use it only as a template engine to construct XML or do you use
> it also to extract information from XML and/or transform it? Most
> complications with E4X comes from the latter, the support for XML
> literals affects only the parser, the runtime support for it is
> trivial. On the other hand XML queries and mutators requires a lot of
> complex code to write and maintain. But if that is not used in custom
> embeddings of SpiderMonkey, then we can consider to remove just that
> part.
That would be excellent IMHO. If this could be retained...
> Do you use it only as a template engine to construct XML or do you use
> it also to extract information from XML and/or transform it? Most
> complications with E4X comes from the latter, the support for XML
> literals affects only the parser, the runtime support for it is
> trivial. On the other hand XML queries and mutators requires a lot of
> complex code to write and maintain. But if that is not used in custom
> embeddings of SpiderMonkey, then we can consider to remove just that
> part.
https://developer.mozilla.org/en/E4X_for_templating
and even generalized to the point that v8 and JSC would consider adopting
it, or some future ECMAScript standard, then it would be a wonderful
addition to the web. This remains the highest starred feature request
for v8 even though it's been closed since last August...
http://code.google.com/p/v8/issues/detail?id=235#c78
Tom Schuster
Jan 4, 2012, 10:43:47 AM1/4/12
to Peter Wilson, dev-tech-...@lists.mozilla.org
I think some uses of the easy inline DOM construction could be helped
with http://wiki.ecmascript.org/doku.php?id=harmony:quasis. Also this
doesn't really generate a tree.
On Wed, Jan 4, 2012 at 2:22 PM, Peter Wilson <pe...@yellowhawk.co.uk> wrote:
> On 03/01/2012 19:27, Tom Schuster wrote:
>> We don't really maintain E4X anymore besides bug fixes, and in the
>> overall scheme of things it even slows down development.
>>
>> a) It makes parsing a lot more difficult as it needs to be.
> But it's done
This not really a reason to keep it. We actually rewrite our code from
time to time, also it's very hard for new people to understand.
actually need E4X on the server.
with http://wiki.ecmascript.org/doku.php?id=harmony:quasis. Also this
doesn't really generate a tree.
On Wed, Jan 4, 2012 at 2:22 PM, Peter Wilson <pe...@yellowhawk.co.uk> wrote:
> On 03/01/2012 19:27, Tom Schuster wrote:
>> We don't really maintain E4X anymore besides bug fixes, and in the
>> overall scheme of things it even slows down development.
>>
>> a) It makes parsing a lot more difficult as it needs to be.
> But it's done
time to time, also it's very hard for new people to understand.
>> b) Some features like objects as properties don't really fit into the
>> modern design anymore.
> Modern design of what? Spidermonkey? Javascript?
Both.
>> modern design anymore.
> Modern design of what? Spidermonkey? Javascript?
>> c) It's dead on the internet, you need to opt-in, and it's Mozilla only.
> May be dead in the browser
Would accept that, also I haven't seen much people stand up, who
> May be dead in the browser
actually need E4X on the server.
Igor Bukanov
Jan 4, 2012, 10:53:24 AM1/4/12
to Mark Constable, dev-tech-...@lists.mozilla.org
On 4 January 2012 16:40, Mark Constable <ma...@renta.net> wrote:
> If this could be retained...
>
> https://developer.mozilla.org/en/E4X_for_templating
That is a nice demonstration of what to keep from E4X - xml literals
> If this could be retained...
>
> https://developer.mozilla.org/en/E4X_for_templating
and parse/serialization methods. No need for all the complexity with
XML property and attribute looks, no need for Namespace and QName etc.
Benjamin Smedberg
Jan 4, 2012, 10:51:40 AM1/4/12
to Mark Constable, dev-tech-...@lists.mozilla.org
On 1/4/2012 8:17 AM, Mark Constable wrote:
>
>
> Why use someone else's idea of someTemplateEngine() when a universal
> E4X engine is built in (other than client side cross browser support).
Because E4X is not cross-browser and at this point it doesn't appear
>
>
> Why use someone else's idea of someTemplateEngine() when a universal
> E4X engine is built in (other than client side cross browser support).
that the other JS engines ever intend on supporting it.
--BDS
Wes Garland
Jan 4, 2012, 11:07:45 AM1/4/12
to Igor Bukanov, dev-tech-...@lists.mozilla.org, Mark Constable
As a data point, I often use E4X for simple parsing, serialization,
templating, and XML literals.
function createDocument()
{
return <html><body>Hello {session.name}</body></html>;
}
is pretty awesome. Then we get the added bonus of sanity-checking by the
spidermonkey compiler during our build process.
I sometimes traverse XML documents like JS object graphs, and sometimes
build them that way, too. I tried looking at the query syntax, and
frankly, it was too complicated for me to bother with.
I also would use E4X in more places if I knew it had a future. As it
stands, I mostly use it for quick-and-dirty hacks, because I need to keep
my production code as future-proof as possible. Which is sad. I really
like the compositing syntax.
Wes
templating, and XML literals.
function createDocument()
{
return <html><body>Hello {session.name}</body></html>;
}
is pretty awesome. Then we get the added bonus of sanity-checking by the
spidermonkey compiler during our build process.
I sometimes traverse XML documents like JS object graphs, and sometimes
build them that way, too. I tried looking at the query syntax, and
frankly, it was too complicated for me to bother with.
I also would use E4X in more places if I knew it had a future. As it
stands, I mostly use it for quick-and-dirty hacks, because I need to keep
my production code as future-proof as possible. Which is sad. I really
like the compositing syntax.
Wes
> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
--
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
--
Peter Wilson
Jan 4, 2012, 12:13:21 PM1/4/12
to
On 04/01/2012 15:43, Tom Schuster wrote:
> I think some uses of the easy inline DOM construction could be helped
> with http://wiki.ecmascript.org/doku.php?id=harmony:quasis. Also this
> doesn't really generate a tree.
I suspect that would take a very long time to be available across browsers and
> I think some uses of the easy inline DOM construction could be helped
> with http://wiki.ecmascript.org/doku.php?id=harmony:quasis. Also this
> doesn't really generate a tree.
to be quite honest not wonderfully intuitive.
>
> On Wed, Jan 4, 2012 at 2:22 PM, Peter Wilson<pe...@yellowhawk.co.uk> wrote:
>> On 03/01/2012 19:27, Tom Schuster wrote:
>>> We don't really maintain E4X anymore besides bug fixes, and in the
>>> overall scheme of things it even slows down development.
>>>
>>> a) It makes parsing a lot more difficult as it needs to be.
>> But it's done
> This not really a reason to keep it. We actually rewrite our code from
> time to time, also it's very hard for new people to understand.
isn't the case with many other technologies
>>> b) Some features like objects as properties don't really fit into the
>>> modern design anymore.
>> Modern design of what? Spidermonkey? Javascript?
> Both.
>>> c) It's dead on the internet, you need to opt-in, and it's Mozilla only.
>> May be dead in the browser
> Would accept that, also I haven't seen much people stand up, who
> actually need E4X on the server.
http://code.google.com/p/v8/issues/detail?id=235#c78
Regardless of the status of E4X on V8 - it's a good set of people standing up
for E4X on the server. There is a comment in there from Brenden I think about
waiting for E5X - no idea what that's going to entail but maybe the approach
should be to stick with E4X in Spidermonkey until E5X has been implemented.
Peter Wilson
Jan 4, 2012, 12:17:42 PM1/4/12
to
technology. There are a lot of financial organisations out there that are
adopting various XML based service interfaces that are *not* going to see JSON
as a viable alernative.
I suspect that JSON is a more appropriate client<->sever technology than
server<->server technology where XML is more at home. Unfortunately the number
of people writing server<->server code is dwarfed by people writing browser code.
Marc Winners
Jan 4, 2012, 11:26:35 PM1/4/12
to
embedded context and would really like to continue to support E4X in
customer scripts, which we call triggers (http://www.extrahop.com/
products/features/application-inspection-triggers/). It's particularly
useful when we see some kind of custom XML application payload---we
can give users the ability to easily parse and extract the particular
information they're interested in, as it happens on their network in
real-time.
Marc Winners
ExtraHop Networks
Biju
Jan 4, 2012, 11:28:52 PM1/4/12
to
We should able to query and manipulate XML.....
I work in IT, ie, supporting/enhancing/maintaining applications that
do high volume of data processing for purchase order and product
configuration systems. We use flat files as well as XML/webservices to
exchange data between systems.
While doing support or when debugging, I use E4X to transform XML to a
human readable format. Even though I do use XSL-FO & XSLT in Apache
FOP, I can tell you working with E4X and JavaScript is way easier as
it also allow to MANIPULATE input XML.
And for me, working on 10 different kinds of XML files of 2MB and more
size is typical for a day.
I also use E4X in testing webservices, I like it way better than
soapUI
I can also tell a large number of application bugs which I fixed where
due to HTML content not escaped properly at JSP/.Net side or
Javascript side.
On Javascript side this is due to web developers not using DOM, but
use string concatenation and .innerHTML, this problem for large extend
would have been avoided if E4X was common in web browsers.
And great if we can fix E4x<->DOM https://bugzilla.mozilla.org/show_bug.cgi?id=270553
So instead of removing E4X from Mozilla, we should have taken time to
evangelize it with other browser vendors.
Cheers
Biju
PS: one of the thing I dont like about MS is, they bring in features,
then we get addicted to it, then they remove it. If Mozilla do the
same, how is that different from MS.
Person who learned/used VI twenty years back can still use VI with out
referring to new manual. That is beauty...
Jeff Walden
Jan 5, 2012, 1:00:24 AM1/5/12
to
On 01/04/2012 07:22 AM, Peter Wilson wrote:
> > a) It makes parsing a lot more difficult as it needs to be.
> But it's done
This assumes that once the parsing code is written, all its costs are paid. This isn't the case. Tom briefly responded to this contention that parsing is now "solved" earlier in the thread; here's a response that goes a bit deeper into the details of why already-written parsing code poses many further costs to SpiderMonkey improvements (and not just to E4X-specific functionality).
> > a) It makes parsing a lot more difficult as it needs to be.
> But it's done
Partly that's due to ancient design decisions to perform both parsing and semantic analysis (associating names with variables and such) in one pass. The current design is in the midst of refactoring which will help to address this. (But see further down.)
Partly it's due to new syntax being added to the language. ES5 "didn't" introduce new syntax, in theory ("use strict" as not-actually-new-syntax seems more a mistake than not in hindsight), but we had to make various improvements to the parser to support it. ES6 or whatever it ends up being called *does* introduce new syntax. Parser changes for this will interact with existing E4X parsing code. (Name analysis code in particular will be hit by this, if we are to implement modules at the speed they were designed to support and with the performance developers will demand from them.)
Partly it's due to ongoing improvements to the general readability and understandability of the parser, which must work around E4X's complexity. You'd be surprised just how much complexity E4X mandates if you were parsing and had just encountered the "." in "foo.bar" and were considering the next possible token. Beyond just the simple "foo.bar" case, I can think of at least eight other semantically distinct possibilities for what might follow. See bug 710941 and bug 713755 for a significant amount of complexity I encountered trying to improve this, with the aim of improving performance for properties in entirely non-E4X-related situations. Getting all the different cases right required a non-trivial amount of work, at least a full day's extra work for E4X-specific complexity just off the top of my head, and probably a bit more. This for something that no other engine will implement.
You should also consider that ECMAScript the language is not evolving in the direction of E4X, and indeed will actively prohibit it in strict mode code. While this means less care need be taken for it in code known to be strict, even just getting that requirement right wasn't trivial. And we must preserve this further requirement in the parser through refactoring.
And of course, parsing code itself is mostly not useful unless it can be compiled into executable bytecode (or native instructions, or whatever). Every additional knob E4X syntax supports means that complexity must carry over into code generation. The cost of existing code there is also not free over time.
Some new functionality, once written, is pretty close to free. Functionality encapsulated in functions poses few problems not raised by other functions. Parser functionality is not free, as interactions of such functionality are generally unique to the particular syntax, must be propagated into code generation and the decompiler, and can affect complex name analysis code.
Jeff
Salvador Ortiz Garcia
Jan 5, 2012, 2:35:27 AM1/5/12
to dev-tech-...@lists.mozilla.org
<rant>
There was a time when you thought that the platform could be much more
than a browser. I and others believed in you and start learning XUL,
XBL, XPCOM, SpiderMonkey, E4X, Gecko embedding, etc. All wonderful and
powerful technologies.
But right now, all the work in the Mozilla Foundation seems to be driven
by the race with other browsers, and in that light, only the raw speed
of the engine matters.
On the road are dying:
- Strong JS introspection capabilities.
- pyxpcom
- Non-chrome XUL
- Activex embedding
- ...
Every few weeks we woke up and fingers crossed wait that the latest
release of XULRunner will not break our embedding projects in
production, see http://jspl.msg.mx/.
All this is very sad.
</rant>
Yes, we have developed and released entire XUL applications that work
just fine til now. They use our XMLTreeView component (nsITreeView
implemented in JS around E4X capabilities) attached as an example.
Regards,
Salvador Ortiz.
0 new messages