Better Native XML Support
I think that requiring a user load a parser to handle XML is perfectly fine. That's the state of the art in most programming languages.
David Bruant wrote:
Have a look at quasis [1]. It provides what I'd consider to be a more generic and safer solution to E4X.
E4X is more than just data production, though. It added a number of accessors/syntax for handling XML elements, many of which can be the LHS of an assignment: expr..ident // descendant selection expr. at ident // attribute selection expr.* // All-children selection expr.(filter) // Filtering a set, with an implicit 'with' @ident // At least within a filter, attribute selection expr.var::ident // Using the namespace in var, descendant selection
In combination, they provide some concise ways of manipulating document-free XML nodes, though with large number of downsides that probably aren't worth covering in detail, here.
It might be worth considering bringing some of those constructs back in a more generic and future-proof fashion in future versions of ECMAScript. Or it might instead be worth considering allowing quasis to be the LHS of an assignment, which would be useful and could then cover more e4x use cases.
(I've removed es5-discuss from the recipients, since this is no longer relevant to that)
, Grant Husbands.
If you desperately need it, you should be able to make a library for it, and then if you need the extra syntax, add an extra compile step - like what coffeescript does. After all, e4x is just an extension to JS, it should be possible to add the data types natively and then make any e4x code work as syntactic sugar, which you can desugar yourself.
I'm not saying its an insignificant effort, but it seems fairly straightforward. The standardized grammar for it is defined as an extension to Ecmascript after all.
On 17 January 2012 13:05, Russell Leggett <russell.leggett at gmail.com> wrote:
After all, e4x is just an extension to JS, it should be possible to add the data types natively and then make any e4x code work as syntactic sugar, which you can desugar yourself.
I don't really know the details, but that is definitely not true. Ask Jeff Walden from Mozilla for details, if you can convince him to discuss the topic. :)
This may be true for "something approaching E4X", and might be a great way to approach the community's needs. An XML library and a pre-processor.
Russell Leggett wrote:
If you desperately need it, you should be able to make a library for it, and then if you need the extra syntax, add an extra compile step
I was simply making sure everyone was on the same page as e4x and was making suggestions to try to bridge the gap. I don't need it myself, though I imagine the "you" there wasn't necessarily aimed at me.
I'm not saying its an insignificant effort, but it seems fairly straightforward. The standardized grammar for it is defined as an extension to Ecmascript after all.
Though source to source processors are a source of significant friction (complicating build and debug), this would indeed be something for the community of e4x supporters to consider. Hopefully, the right people will see this thread.
I think that assignment into quasis may yet be useful, but perhaps it doesn't belong in this thread.
, Grant Husbands.
On Tue, Jan 17, 2012 at 1:30 PM, Wes Garland <wes at page.ca> wrote:
On 17 January 2012 13:05, Russell Leggett <russell.leggett at gmail.com>wrote:
After all, e4x is just an extension to JS, it should be possible to add the data types natively and then make any e4x code work as syntactic sugar, which you can desugar yourself.
I don't really know the details, but that is definitely not true. Ask Jeff Walden from Mozilla for details, if you can convince him to discuss the topic. :)
Ah, that's too bad. I'll admit I hadn't looked at it quite in depth enough to say for sure, but it seemed fine from my limited knowledge. I guess not.
On Tue, Jan 17, 2012 at 1:30 PM, Grant Husbands <esdiscuss at grant.x43.net>wrote:
Russell Leggett wrote:
If you desperately need it, you should be able to make a library for it, and then if you need the extra syntax, add an extra compile step
I was simply making sure everyone was on the same page as e4x and was making suggestions to try to bridge the gap. I don't need it myself, though I imagine the "you" there wasn't necessarily aimed at me.
Yeah, not directed at you. Couldn't remember how the thread started. You seemed to be an advocate so that's where I went with it. Sorry.
I'm not saying its an insignificant effort, but it seems fairly straightforward. The standardized grammar for it is defined as an extension to Ecmascript after all.
Though source to source processors are a source of significant friction (complicating build and debug), this would indeed be something for the community of e4x supporters to consider. Hopefully, the right people will see this thread.
It is a source of friction, but its also extremely commonplace now. I imagine something like an e4x pre-processor would output code that was pretty easy to debug as well, and it sounds like we'll be seeing source mapped debuggers soon enough.
Le 16/01/2012 18:30, Nuno Job a écrit :
Have a look at quasis [1]. It provides what I'd consider to be a more generic and safer solution to E4X. You can send feedback to es-discuss at mozilla.org (es5-discuss is usually reserved to ECMAScript 5 specifically, though most people who are in one are certainly in both)
David
[1] harmony:quasis