Re: ES4 draft: Namespace
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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Namespace
> -Original Message- > From: Waldemar Horwat [mailto:[EMAIL PROTECTED] > Sent: 21. mars 2008 15:10 > To: Lars Hansen > Cc: es4-discuss@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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Namespace
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.
--lars
Title: The class "Namespace"
The class Namespace
NAME: "The class 'Namespace'"
FILE: spec/library/Namespace.html
CATEGORY: Pre-defined classes
SOURCES:REFERENCES [1], [2]
SPEC AUTHOR:Lars
DRAFT STATUS: DRAFT 3 - 2008-03-20
REVIEWED AGAINST ES3: N/A
REVIEWED AGAINST ERRATA:N/A
REVIEWED AGAINST BASE DOC: YES
REVIEWED AGAINST PROPOSALS: N/A
REVIEWED AGAINST CODE: YES
REVIEWED AGAINST TICKETS: YES
IMPLEMENTATION STATUS: ES4 RI (partly)
TEST CASE STATUS: ?
CHANGES SINCE DRAFT 2 (2008-03-17)
* There is a public constructor for Namespace objects
* The 'Namespace' class object can be invoked as a function
* There is a getter for a 'name' property on Namespace objects
* The 'toString' method is tagged "override"
* Presentation: More elaborate status block above
CHANGES SINCE DRAFT 1 (2008-03-05)
* Presentation: added an explicit "extends Object" clause
* Namespaces are explicitly designated nullable and a null value is
tied to the compatibility namespace noNS
* The behavior of the 'toString' method has been tightly specified
to allow Namespace objects to be compared predictably
NOTES
* "Forgeable" and "unforgeable" namespaces are discussed in the
language spec. A forgeable namespace is created from a string, as
with 'namespace f = "my namespace"'. An unforgeable namespace is
created not from a string, as with 'namespace u'
* The constructor and the 'name' getter are compatible with E4X
REFERENCES
[1] Section 4.2.10.4 of the base document: http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%3Aresources&cache=cache&media=resources:as3lang.doc
[2] builtins/Namespace.es in the ES4 RI
[3] Language definition, section on Names (forthcoming).
The class Namespace is a final, non-dynamic, nullable,
direct subclass of Object.
NOTE Namespace values can be created by new expressions in
the user program or by the evaluation of a namespace definition,
which creates a new namespace and a constant binding for it.
COMPATIBILITY NOTE The Namespace class is new in the 4th Edition of this
Standard.
Synopsis
The class Namespace provides the following interface:
__ES4__ final class Namespace extends Object
{
public function Namespace(name=undefined) …
static meta function invoke(x) …
static public const length = 1
override intrinsic function toString(): string …
public function get name(): (string|undefined) …
}
The Namespace prototype object provides the following direct
properties:
toString: function () …
Operators
The operators == and === compare forgeable Namespace
objects by comparing their names as obtained by the name accessor,
see below. Forgeable namespaces with the same name are equal by those
operators.
In all other cases, Namespace objects are equal only to
themselves.
Methods on the Namespace class object
new Namespace(name=…)
Returns When the Namespace constructor is called with no arguments
or with the argument undefined it returns a new unforgeable
Namespace object. The returned object is unequal to every
previously existing Namespace object.
When the Namespace constructor is called with an argument
name that is not undefined it converts name to string and
returns a new forgeable namespace whose name is the converted value.
Implementation
public function Namespace(name=undefined) …
Namespace(x)
Returns The Namespace class object called as a function returns a
Namespace object. If x is a Namespace object then it is
returned. Otherwise a new Namespace object is constructed by
invoking the Namespace constructor on x.
Implementation
static meta function invoke( x ): Namespace! {
if (x is Namespace!)
return x;
return new Namespace(x);
}
Methods on Namespace instances
intrinsic::toString()
Description The intrinsic toString method converts the Namespace
object to a string. If the Namespace object is forgeable (it was
created with an explicit name) then the string returned by
toString contains the name as a substring.
Returns The toString method returns an implementation-defined
string.
Suppose the intrinsic toString method is invoked on two
namespaces N1 and N2 yielding strings T1 and T2,
respectively. T1 and T2 are equal if and only if N1 is
equal to N2 (by === or ==).
Suppose the intrinsic toString method is invoked on two
different forgeable namespaces N1 and N2 created from strings
S1 and S2, yielding strings T1 and T2, respectively.
T1 and T2 have the same relationship (determined by the
rela
RE: ES4 draft: Namespace
Draf 2 of the spec for Namespace objects.
--lars
Title: The class "Namespace"
The class Namespace
FILE: spec/library/Namespace.html
DRAFT STATUS: DRAFT 2 - 2008-03-17
SOURCES:REFERENCES [1], [2]
REVIEWED AGAINST ES3: N/A
REVIEWED AGAINST ERRATA:N/A
REVIEWED AGAINST BASE DOC: YES
REVIEWED AGAINST PROPOSALS: N/A
REVIEWED AGAINST CODE: YES
IMPLEMENTATION STATUS: ES4 RI (partly)
CHANGES SINCE DRAFT 1 (2008-03-05)
* Presentation: added an explicit "extends Object" clause
* Namespaces are explicitly designated nullable and a null value is
tied to the compatibility namespace noNS.
* The behavior of the 'toString' method has been tightly specified
to allow Namespace objects to be compared predictably.
OPEN ISSUES
* Namespace objects in ES4 are more opaque than the Namespace
objects in the base document and in E4X, both of which expose
"prefix" and "name" properties. ES4 is not supporting E4X, and
the base document was probably influenced by E4X, so this
may not be a big deal, but it should be discussed.
REFERENCES
[1] Section 4.2.10.4 of the base document: http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%3Aresources&cache=cache&media=resources:as3lang.doc
[2] builtins/Namespace.es in the ES4 RI
[3] Language definition, section on Names (forthcoming).
The class Namespace is a final, non-dynamic, nullable,
direct subclass of Object. It reflects a namespace as an opaque
datum.
NOTE Namespaces are created as a result of the evaluation of the
namespace pragma, which defines a new namespace and creates a
binding for it. Namespaces are reflected as Namespace objects
when namespace bindings are referenced in expressions.
NOTE A Namespace object can be created with an explicit name by
providing the name as a string in the namespace pragma.
NOTE Generally a null namespace value is used to denote the
compatibility namespace noNS.
COMPATIBILITY NOTE The Namespace class is new in the 4th Edition of this
Standard.
Synopsis
The class Namespace provides the following interface:
__ES4__ final class Namespace extends Object
{
intrinsic function toString(): string …
}
The Namespace prototype object provides the following direct
properties:
toString: function () …
Operators
The operators == and === compare as equal two non-opaque
Namespace objects that are separately created from the same string;
similarly, the operators != and !== compare as not equal two
Namespace objects that are separately created from dissimilar strings.
Methods on the Namespace class object
There are no methods on the Namespace class object. In
particular, the class Namespace does not have a publicly
accessible constructor.
Methods on Namespace instances
intrinsic::toString()
Description The intrinsic toString method converts the Namespace
object to a string. If the Namespace object was created with an
explicit name then the string contains that name as a substring.
Returns The toString method returns an implementation-defined
string.
Suppose the intrinsic toString method is invoked on two
namespaces N1 and N2 yielding strings T1 and T2,
respectively. T1 and T2 are equal if and only if N1 is
equal to N2 (by === or ==).
Suppose the intrinsic toString method is invoked on two
different non-opaque namespaces N1 and N2 created from strings
S1 and S2, yielding strings T1 and T2, respectively.
T1 and T2 have the same relationship (determined by the
relational operators) as S1 and S2.
Methods on the Namespace prototype object
Description The methods on the Namespace prototype object delegate to
their corresponding intrinsic methods.
Returns The methods on the Namespace prototype object return what
their corresponding intrinsic methods return.
Implementation
prototype function toString(this:Namespace)
this.intrinsic::toString()
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
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. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Namespace
> I 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 ... > always yields the same string. Doesn't seem > particularly onerous, it would probably be the case in most > implementations anyhow. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Namespace
> -Original Message- > From: Waldemar Horwat [mailto:[EMAIL PROTECTED] > Sent: 13. mars 2008 17:35 > To: Lars Hansen > Cc: es4-discuss@mozilla.org > Subject: Re: ES4 draft: Namespace > > 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. 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. Then the same property for Name follows, since the string representation for a Name is defined to be either the identifier string if there's no Namespace part or the concatentation of the string representation of its Namespace, "::", and its identifier string otherwise. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
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. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Namespace
> -Original Message- > From: Waldemar Horwat [mailto:[EMAIL PROTECTED] > Sent: 12. mars 2008 18:54 > To: Lars Hansen > Cc: es4-discuss@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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
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". (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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
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. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
On 3/8/08, zwetan <[EMAIL PROTECTED]> wrote: > do I understand well that E4X will be removed from ES4 ??? It was never in ES4 to begin with. --lars > 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 > http://dev.abiss.gr/sarissa/ > http://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 > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
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 http://dev.abiss.gr/sarissa/ http://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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
Just for completeness -- we implement it in Mbedthis Ejscript also. Mob Brendan Eich wrote: On Mar 5, 2008, at 11:51 PM, T. Michael Keesey wrote: On Wed, Mar 5, 2008 at 11:28 PM, Brendan Eich <[EMAIL PROTECTED]> 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? /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
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". /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
On Mar 5, 2008, at 11:51 PM, T. Michael Keesey wrote: > On Wed, Mar 5, 2008 at 11:28 PM, Brendan Eich <[EMAIL PROTECTED]> > 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? /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
On Wed, Mar 5, 2008 at 11:28 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > > E4X is not used on the Web. So ActionScript 3.0-based Flash/Flex websites don't count? -- T. Michael Keesey Director of Technology Exopolis, Inc. 2894 Rowena Avenue Ste. B Los Angeles, California 90039 http://exopolis.com/ -- http://3lbmonkeybrain.blogspot.com/ ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
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 http://wiki.ecmascript.org/doku.php? id=clarification:type_system#relax-ng_types /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Namespace
>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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Namespace
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. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: 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 -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen Sent: Wednesday, March 05, 2008 5:02 PM To: es4-discuss@mozilla.org Subject: ES4 draft: Namespace Namespace objects represent reflected namespaces. Here's the (short) draft spec. Comments welcome. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
