Actually, it’s not really necessary to allow null and undefined to get an empty XML object. The constructor can default to en empty string. So an empty string could get an XML object while null and undefined could throw an error.
That might make more sense because it would likely catch more errors. > On Jul 18, 2017, at 11:07 AM, Harbs <harbs.li...@gmail.com> wrote: > > I discovered that the documentation on the top level functions is wrong. > > According to the docs[1] the only valid expressions for XML and XMLList are: > XML, XMLList, Boolean, Number and String. Anything else is supposed to throw > an error. > > What actually happens is that null and undefined are simply swallowed and you > get an empty XML text node object. Everything else simply has toString() > called on it, so if you pass in an Object which does not have an > implementation of toString(), you’ll get a text node with a value of [object > Object]. > > In my tests, new XML() and XML() behave identically. > > That’s not what I’d call great behavior… > > So the question is what to do. What I think makes sense is to make toXML() > behave like the docs and new XML() behave like the observed behavior. At the > least for null and undefined. There needs to be a way to instantiate an empty > XML object. I’m on the fence about objects. I’m leaning toward always > throwing an error if the argument is an object. > > Thoughts? > > Harbs > > [1]http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/package.html#XML() > > <http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/package.html#XML()> > >> On Jul 18, 2017, at 8:20 AM, Harbs <harbs.li...@gmail.com >> <mailto:harbs.li...@gmail.com>> wrote: >> >> I’ll try to write these functions today. >> >
