Closed Bug 509705 Opened 15 years ago Closed 15 years ago

"with" statement does not work correctly with e4x

Categories

(Core :: JavaScript Engine, defect)

1.8 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mattes, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090806 Gentoo Firefox/3.5.2
Build Identifier: SpiderMonkey 1.8.0-rc1

When the "with" statement is used on an xml object, some other object seems to be "withed". toString() returns "[object global]". This also affects e4x filters. 

Reproducible: Always

Steps to Reproduce:
1. Run "js -f problem1.js"

Actual Results:  
[object global]

<doc>
  <foo>text1</foo>
  <foo>text2</foo>
</doc>


Expected Results:  
<foo>text1</foo>
<foo>text1</foo>
Version: unspecified → 1.8 Branch
IIRC this is per ECMA-357 -- ain't E4X great?

/be
Where does ECMA-357 say this? Section 11.1 shouldn't change the meaning of "with" when applied to xml objects.
E4X makes methods not appear to be properties. You have to call them to get them.

See 7.1.2, 7.1.5, and specifically 9.1.1.6 [[HasProperty]](P) -- then see ECMA-262 Edition 3 10.1.4 Scope Chain and Identifier Resolution.

Dammit, you made me read ECMA-357 again :-/.

/be
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Adobe apparently interprets ECMA-357 differently for ActionScript. Go to 
http://eval.hurlant.com/demo/ and try this script:

var x = new XML ('<foo><bar>one</bar><bar>two</bar></foo>');
with(x.bar[0]) {
  Util.print(toString());
}

It prints "one".
There's no difference in interpretation, Adobe (Michael Daumling, perhaps) has extended E4X in this and other ways.

I have no intention of throwing good money after bad, for my part.

/be
OK. In the meantime I read 9.1.1.6 and understood why E4X is supposed to behave that way.
E4X has some convenient ideas and concrete syntactic extensions to JS, but the spec is full of very wrong "Do what I mean" magical-wannabe-Perl ideas such as implicit conversion from XMLList to only element to string (to pick one example).

JS has enough implicit converion badness of this sort (my fault; in my defense it was the 90s and all the rage :-P -- seriously, no excuses). E4X ups the ante in ways that are hard to predict and reason about even dynamically.

Worse, changing methods to be hidden from property access does real violence to JS's "methods are function-valued properties" design. One cannot use apply, e.g. In SpiderMonkey I extended E4X with the function:: namespace so one could get at methods by unqualified name (try your with test with function::toString() as the call instead of toString()).

The worst aspect of ECMA-357 is how it is obviously unchecked, buggy pseudo-code that was translated from the sole (at the time the standard was written) buggy implementation (written in Java, contributed to Rhino), with nothing like a type system (see Pierce et al.'s XDuce [1]) to prevent cycles and join points in the XML graph that should be a tree but may not be after certain E4X operations.

Indeed such errors existed in the spec before I reported and helped fix them -- but these were fixed only by patching the horribly complicated random logic of [[Put]], [[Get]], etc.

E4X filters recreate all the optimization and programmer reasoning hazards of with statements.

The spec may still say this, I forget: in JS, mentioning x where no such name is in scope results in a (runtime) Reference error. In E4X, mentioning y::z or *::w or even just * as an operand evaluates to undefined! This is way too loosy-goosey, it hides only errors.

There are a lot of "don't" lessons here, more than the few "do" successes or good ideas with so-so concrete realizations. I joke about a successor "E5X". It would not be a compatible superset.

/be

[1] See XDuce section at http://www.cis.upenn.edu/~bcpierce/
IIRC, Michael Daumling also fixed a bug in E4X where new XML("<?xml ...?>...") is invalid because the spec says to wrap that document source with its initial XML declaration in a <parent xmlns="...">...</parent> container. The spec does this only to set the default XML namespace, but it could do so otherwise without the abstraction break that leaks as a user-hostile prohibition on XML declarations or indeed lists of elements as XML document sources.

OTOH, allowing XML decls makes it even easier to attach XML data behind a firewall by loading it as JS. See bug 336551 and bug 375250.

/be
(In reply to comment #9)
> OTOH, allowing XML decls makes it even easier to attach XML data behind a
> firewall by loading it as JS. See bug 336551 and bug 375250.

s/attach/attack/

This is a serious problem if not addressed outside of the Ecma specs. It's solved now (bug 375250).

/be
Brendan, thanks for "function::", solves my problem. Perhaps it should be documented. See also bug 300413.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: