extracting namespace from a property

Brendan Eich brendan at mozilla.org
Thu Feb 15 10:21:25 PST 2007


On Feb 15, 2007, at 6:43 AM, Jeff Walden wrote:

> Igor Bukanov wrote:
>> Prefixes are optional E4X feature that an implementation may choose
>> not to support.
>
> Yeah, that's nice -- problem is that it really only works if  
> everyone agrees not to expose prefixes or the spec mandates it, and  
> since most other things preserve prefixes it's feature compat  
> (everyone expects it or uses something else).  I like the effort,  
> but personally I think it was too late to try, a worse-is-better  
> scenario.

Yes, this is a case where ECMA-357 followed wimpy ECMA-262 by  
allowing too much to be decided by the implementation. That makes for  
interop hell until there's a winner, when everyone else must follow  
the leader. One could argue that it's better than the spec (written  
based on one implementation) deciding in advance of adoption and  
experience, but I believe that prefix preservation is what people  
want from E4X. The spec should have just said so.

>> They are only necessary to preserve the initial
>> prefixes in the serialized XML. So perhaps E4X namespace can subclass

(QName, not Namespace, I think Igor meant by "E4X namespace".)

>> the Name class?
>
> I think I could go for that, although since you can't guarantee |n  
> is Name| forall |for (var n in obj)|, I'm not sure doing so is  
> really a useful gain.

If QName <: Name it still helps a bit. But yeah, Name is not related  
to string type as discussed previously, so at least one type test  
would be needed for uses of n in the loop body that did something  
more involved, say parse n as a string, than what almost all such  
loops do, obj[n].

/be




More information about the Es4-discuss mailing list