Have I found a bug in AS3's XML class?

Let's state a few facts upfront:

Livedocs tells us that dynamic classes enable us to add member variables and member functions. We are told that all classes ultimately derive from Object, which is dynamic, and that dynamic classes must be explicitly marked as such -- inheritance doesn't apply to dynamism.

Object is a dynamic class. Date is a final dynamic class. XML is a final dynamic class. You can create your own final dynamic class and it ought to behave (in terms of dynamic capability) exactly as do XML and Date, above. In fact, final should开发者_如何转开发n't affect the issue at hand at all but I include it for exactness in my comparison against the "troubled" XML class.

My code:

public static function setup():void//Object
{
    //Uncomment each in turn to get results:
    //var o:Object = {};
    //var o:MyFinalDynamicClass = new MyFinalDynamicClass();
    //var o:Date = new Date();
    //var o:XML = new XML();

    o.foo = function():String
    {
        return "Works as expected.";
    }

    trace(o.foo());
}

The results for enabling each of the lines where o is defined:

Object: Works as expected.

MyFinalDynamicClass: Works as expected.

Date: Works as expected.

XML: TypeError: Error #1006: value is not a function.

I used Date as it is another core class that is final dynamic. Also note that member variables work just fine in all of the above classes. Only member functions have a problem, and only in class XML.

My conclusion is that not every class in AS3 is derived from Object, some are likely mocked up to look that way but are in fact derived in some other way in native C++, which I believe is what Adobe uses to write the AS languages.

QUESTION: Do you see any flaws in my logic? Or is this class actually bugged?

P.S. For those interested as to why I wanted to add functions to XML, I wanted a way to encapsulate complex access to my XML data model.

According to livedocs, XML is indeed derived from Object. Furthermore, I don't think this is a bug at all but rather the expected behavior of the XML class. It's simply rejecting your method, because it's not an XML object. Think of it as a runtime checked typed tree. You can only get/set other XML objects. Try this following example:

var foo:XML = <foo><bar /><bar /></foo>;
trace(foo); // Prints <foo><bar /></foo>

foo.bar = <baz />;
trace(foo); // Prints <foo><baz /></foo>

The XML object is an ActionScript representation of the XML, so what's happening is effectively that I'm taking all of the tags and replacing them with a single tag. If you try to replace the XML with something that isn't XML (i.e. your method), it's not going to understand what it is you want and will convert the value into a string. The result will then be something like:

<foo>
  <bar>function Function() {}</bar>
</foo>

You will need to build a wrapper that takes care of your processing instead.

It's not a bug. The e4x object allows you to manipulate the child elements of the XML dom using normal object notation. This is further elaborated upon here. So, when you assign the function to an attribute of the XML object, the function gets converted to a string, and the string is then added to the XML document as the text value of the <foo> element.

Another quirk of e4x is that, without a root-level element, it'll more-or-less ignore any attempt to set child elements. So consider the following:

var o:XML = new XML('<document/>');

o.foo = function():String {
    return "Works as expected.";
};

trace(o.toXMLString());

prints:

<document>
    <foo>function Function() {}</foo>
</document>

Another Actionscript3 object that works like this is Proxy. Proxy is not final, which would allow you to build your own class that works just like the e4x XML class.

I think you have probably run into some E4X related issue, so yes, I'd agree this is probably a bug.

You should be able to post it to Adobe's Jira system at : http://bugs.adobe.com/jira/browse/FP

I don't think there is a way around this bug. your totally right but at the same point how would they implement the E4X logic without the xml being dynamic if it wasn't dynamic it wouldn't be capable of the E4X features. at the same time i think they added this logic into the object so users don't get confused with methods that the XML doesn't support in a way its like a dynamic that isn't really fully dynamic.