ES4 draft: Namespace
Unfortunately, I am not familiar with the decision to not support E4X in ES4. Would this decision not Break The Web, as E4X has been an integral part of SpiderMonkey for a long time?
Anyway, what advantage does the hiding of the prefix and name properties have? Shouldn't we at least be aware of possible E4X users on the Web, and stay as compliant to E4X, even if ES4 does not support E4X?
FYI: Adobe products are not The Web (but Flash is), but they integrate either ActionScript, SpiderMonkey or ExtendScript, and all languages support E4X.
Michael
On Mar 5, 2008, at 11:23 PM, Michael Daumling wrote:
Unfortunately, I am not familiar with the decision to not support
E4X in ES4. Would this decision not Break The Web, as E4X has been an
integral part of SpiderMonkey for a long time?
Certainly it won't break the Web, since the Web has to run in
multiple browsers and SpiderMonkey is only in Firefox.
What's more, we are reserving E4X syntax, but the E4X spec is a
glorious mess of buggy pseudo-code, transcribed from buggy Java code.
It is nearly impossible to reason about the deep logic levels and ad-
hoc special-casing of [[Get]] and [[Put]] on XML types, e.g., to be
able to prove to oneself that only trees and not DAGs or cyclic XML
structures ever can result from a series of E4X operations. E357 is
the anti-spec as far as mechanization and readability are concerned,
in my view.
Anyway, what advantage does the hiding of the prefix and name
properties have? Shouldn't we at least be aware of possible E4X users on the Web, and stay as compliant to E4X, even if ES4 does not support E4X?
E4X is not used on the Web.
FYI: Adobe products are not The Web (but Flash is), but they integrate either ActionScript, SpiderMonkey or ExtendScript, and all languages support E4X.
According to what edition of ECMA-357, with what unfixed and fixed
errata? Tested interoperably with other implementations (say,
SpiderMonkey's) how?
E4X can be a useful tool. It was a grand experiment in its time,
helping to rekindle ECMA TC39 TG1. But it needs a rethink, and a
sound spec.
According to what edition of ECMA-357, with what unfixed and fixed
errata?
Tested interoperably with other implementations (say, SpiderMonkey's) how?
I can only speak for ExtendScript. E4X was implemented according to ECMA-357 2nd edition, and it is tested using the SpiderMonkey test suite. Unfortunately, the ECMA Web site does not offer any errata documents, so I am not aware of their existence. So there is hope that ExtendScript is compatible with SpiderMonkey re E4X :-)
Are there any plans to revisit and update ECMA-357? E4X has shown to be extremely useful as such.
Michael
On Mar 5, 2008, at 11:37 PM, Michael Daumling wrote:
I can only speak for ExtendScript. E4X was implemented according to ECMA-357 2nd edition, and it is tested using the SpiderMonkey test suite. Unfortunately, the ECMA Web site does not offer any errata documents, so I am not aware of their existence. So there is hope that ExtendScript is compatible with SpiderMonkey re E4X :-)
The tests are good but coverage is what you should expect from hand-
written unit/basic-functional tests, plus regression tests. We've
found and fixed stuff that was clearly not anticipated by the spec
authors (including the ability to make cyclic XML structures), and
hairier edge-case by fuzz-testing.
Are there any plans to revisit and update ECMA-357? E4X has shown
to be extremely useful as such.
After ES4. See also
doku.php? id=clarification:type_system#relax
On Wed, Mar 5, 2008 at 11:28 PM, Brendan Eich <brendan at mozilla.org> wrote:
E4X is not used on the Web.
So ActionScript 3.0-based Flash/Flex websites don't count?
On Mar 5, 2008, at 11:51 PM, T. Michael Keesey wrote:
On Wed, Mar 5, 2008 at 11:28 PM, Brendan Eich <brendan at mozilla.org>
wrote:E4X is not used on the Web.
So ActionScript 3.0-based Flash/Flex websites don't count?
Sorry, my browser bias is showing.
Sure, E4X is in Flash. Interoperating with itself. Same goes for
SpiderMonkey. It's not part of the cross-browser standards that are
implemented in standards, and Michael suggesting that not
standardizing E4X in ES4 somehow "breaks the Web" is frankly too much.
Now that we've reconnected to Michael's original message and (I hope)
dealt with the "break the Web" non-threat, are you concerned about
E4X not being in ES4 for some other reason?
On Mar 6, 2008, at 12:26 AM, Brendan Eich wrote:
Sure, E4X is in Flash. Interoperating with itself. Same goes for SpiderMonkey. It's not part of the cross-browser standards that are implemented in standards,
er, "implemented in browsers".
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20080306/dc6c0b2a/attachment-0002
do I understand well that E4X will be removed from ES4 ???
this is so wrong i can not even believe it...
try to parse XML in .NET/Java/PHP/whatever... the ONLY elegant and straightforward way to do it is E4X imho
but ok let's stay on the standard and on the web, look at how browsers parse XML without E4X
see why those projects exists dev.abiss.gr/sarissa, code.google.com/p/ajaxslt
yeah that's the reality in browsers XML parsing sucks because every browser does its own cooking...
so again, even if the E4X spec is buggy etc. would it not be better to keep E4X and/or try to improve it within ES4 ?
I know this ML is focused on specs, but I can really not understand why something as E4X which is easy and powerfull to use for any dev would be removed
zwetan
On Mar 8, 2008, at 8:58 PM, zwetan wrote:
do I understand well that E4X will be removed from ES4 ???
Not removed, not included. It's a separate Ecma standard. As I wrote
(you read :-/), the spec is in poor enough shape, and feedback from
our users suggest enough changes, that we didn't want to delay ES4 to
include it.
More important, we do not believe it is proper to mandate E4X support
as a normative part of ES4. ES3 is implemented in very small devices
and used by many other standards. Some of those implementations and
standards have nothing to do with XML.
this is so wrong i can not even believe it...
What would be wrong is your apparent stance: require all ES3
implementations contemplating ES4 to implement E4X, even if XML is
irrelevant.
Your message goes on to decry the state of XML parsing in browsers,
but E4X is not really an XML parser. It is out of date regarding XML
1.1 and namespaces. It has no provision for streaming (SAX-style
parsing). Its "DOM" duplicates the browsers' DOMs with gratuitous
differences, yet (optionally) requires the two DOMs to be
synchronized. How mandating E4X as part of ES4 would help XML parsing
in browsers is beyond me.
Here's my review of this section:
Is null a valid value of the class Namespace? The description states that it is a "final, non-dynamic, direct subclass of Object".
(Maybe this is addressed somewhere else, but I haven't seen it yet.) What do ==, <, etc. do on Namespaces? Can I create a Map with Namespace as the key?
Waldemar-----Original Message----- From: Waldemar Horwat [mailto:waldemar at google.com] Sent: 12. mars 2008 18:54 To: Lars Hansen Cc: es4-discuss at mozilla.org Subject: Re: ES4 draft: Namespace
Here's my review of this section:
Is null a valid value of the class Namespace? The description states that it is a "final, non-dynamic, direct subclass of Object".
I don't recall us ever discussing whether it is nullable or not. I have no strong opinions. There is a natural initializer value for Namespace, namely the compatibility namespace "noNS" (Jeff's writeup on these matters is forthcoming). So it could be non-nullable.
Opinions from others are solicited...
(Maybe this is addressed somewhere else, but I haven't seen it yet.) What do ==, <, etc. do on Namespaces? Can I create a Map with Namespace as the key?
As written up elsewhere, == and === probably ought to compare two Namespace objects created from the same string [through the use of the syntax
namespace ns = "mystring"
since there's no public constructor for Namespace] as equal.
The natural behavior on < etc would be as in ES3, ie, if valueOf on namespace returns "this", as is most natural, then the toString() operator ends up being called, and the string names of the namespaces would be compared. Since the string representation is not specified, there is no specified ordering, but unless the implementation randomizes the output of toString, it should at least be dependable per-implementation. We could add a constraint to toString that says that if two namespaces N1 and N2 are created from strings S1 and S2 then N1 and N2 compare the same as S1 and S2. (For unforgeable namespaces -- those created without an explicit string name -- all bets are off, and no two are equal.)
Can you create a Map with a namespace as a key? Presumably you mean with the default comparator and hashcode values. Yes, you can, because the spec for intrinsic::hashcode says that if v1 === v2 then we must have hashcode(v1) == hashcode(v2). (Incidentally this means that the implementation for hashcode must behave specially for Namespace and Name objects, once we settle the rules for ===.)
Lars Hansen wrote:
The natural behavior on < etc would be as in ES3, ie, if valueOf on namespace returns "this", as is most natural, then the toString() operator ends up being called, and the string names of the namespaces would be compared. Since the string representation is not specified, there is no specified ordering, but unless the implementation randomizes the output of toString, it should at least be dependable per-implementation. We could add a constraint to toString that says that if two namespaces N1 and N2 are created from strings S1 and S2 then N1 and N2 compare the same as S1 and S2. (For unforgeable namespaces -- those created without an explicit string name -- all bets are off, and no two are equal.)
Do we ever want to allow for any ordered containers analogous to C++'s map<> and set<>? If we were to define one then this could cause problems because an ordered container typically uses a less-than comparison function and considers x and y to be equal if neither x < y nor y < x holds.
The actual order wouldn't matter, as long as two different namespaces wouldn't appear equal to each other in the above sense.
WaldemarI suppose we could simply state that two Namespaces yield the same string value iff they are ===, and that two invocations of toString()
... on the same Namespace object ...
On Mar 13, 2008, at 4:43 PM, Lars Hansen wrote:
I suppose we could simply state that two Namespaces yield the same string value iff they are ===, and that two invocations of toString() always yields the same string. Doesn't seem particularly onerous, it would probably be the case in most implementations anyhow.
Let's specify this.
Draf 2 of the spec for Namespace objects.
Draft 3 of the Namespace spec. This introduces the ability to construct namespaces at run-time without having to resort to eval, and with it comes the ability to pick the namespace name out of the Namespace object and also to call the Namespace class as a function in the style of all the other classes.
Please define the terms "forgeable" and "unforgeable" in the synopsis before using them later.
Why is name a function instead of a property? The behavior is the same (I think), but it's harder for the reader to figure out that the name won't change over time. I'm asking why you chose to describe it as a function while similar things in other chapters are described as properties.
Waldemar-----Original Message----- From: Waldemar Horwat [mailto:waldemar at google.com] Sent: 21. mars 2008 15:10 To: Lars Hansen Cc: es4-discuss at mozilla.org Subject: Re: ES4 draft: Namespace
Please define the terms "forgeable" and "unforgeable" in the synopsis before using them later.
The terms are (will be) defined in the language part of the spec, and there is already an entry in the NOTES section that defines what they mean for the moment, since the language part does not yet exist. Will that not suffice?
(I don't mind judicious redundancy in the spec, but my judgement was that this is an occasion for that. I'm not wedded to that opinion.)
Why is name a function instead of a property? The behavior is the same (I think), but it's harder for the reader to figure out that the name won't change over time. I'm asking why you chose to describe it as a function while similar things in other chapters are described as properties.
This looks like unfinished cleanup. It should definitely be a const property.
Lars Hansen wrote:
Please define the terms "forgeable" and "unforgeable" in the synopsis before using them later.
The terms are (will be) defined in the language part of the spec, and there is already an entry in the NOTES section that defines what they mean for the moment, since the language part does not yet exist. Will that not suffice?
I don't know; I'm reviewing the sections based solely on the text you've shared so far, so the questions I note might be answered in parts I haven't seen yet. In this case I'm not sure what you mean by the "language part of the spec"; ES3 has an overview but it's non-normative.
Waldemar
Namespace objects represent reflected namespaces. Here's the (short) draft spec.
Comments welcome.