OK. This approach is different than the approach I started on, but it could be
workable.
I was going down the road where there would be a set of single new classes
which would proxy to XML and Document in Flash and HTML respectively. You are
suggesting we stick with XML and XMLList for Flash and create new JS versions
with the same public API as XML and XMLList.
Where would you go about creating those JS classes? Would I just out it in an
“as” folder and wrap the whole class in a COMPILE::JS? Also, what package would
this go into? I’m assuming none, since XML and XMLList are both top level
classes.
BTW, I need to read and write XML files, so yeah, converting to JSON is not an
option.
On Nov 10, 2015, at 1:28 AM, Alex Harui <aha...@adobe.com> wrote:
> Renaming the thread
>
> On 11/9/15, 1:12 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> Well, I’d be interested in your findings.
>>
>> If operator definitions is possible .. will be easier than . operators.
>> If we allow single dot operators, it will be difficult to differentiate
>> between E4X syntax and function calls. I’d really like to drop the () on
>> length and some of the other methods… Those are a course for very common
>> errors.
>
> Maybe we aren’t talking about the same thing, but let me explain in more
> detail what I’m saying.
>
> Here is some E4x:
>
> var a:XML = new XML(\"<top attr1='cat'><child attr2='dog'><grandchild
> attr3='fish'>text</grandchild></child></top>\”);
> var b:XMLList = a..child;
> var c:XMLList = a..grandchild.(@attr2 == 'fish');
>
>
> (It would be nice to have others add in their favorite or common scenarios
> if they are different).
>
> The compiler already understands the “..” as well as the “@“. The way
> Falcon and FalconJX works is that there is a parsing phase that takes your
> source code and creates a tree of different kinds of nodes (ClassNodes,
> FunctionNodes, FunctionCallNodes, OperatorNodes,
> MemberAccessExpressionNodes, etc). Falcon then walks the tree and
> converts these nodes to ABC. FalconJX walks the tree and outputs
> JavaScript.
>
> I just ran a test and the above code was parsed into a tree where the “..”
> was the operator for a MemberAccessExpression. The “@“ was converted into
> a unary operator for an E4xFilter operator for another
> MemberAccessExpression. This is good for FalconJX, because that means we
> understand the semantics of this syntax and can then generate any
> JavaScript we want.
>
> IMO, given that folks are already wishing for a more Spark and MX-like
> component set, I think we should try to mimic as much of E4x as possible
> as opposed to inventing a new API that folks would have to migrate to.
> Performance-wise, I still think it would be worth everyone’s time to
> convert XML to JSON, but there are probably folks who can’t move.
>
> Given that FlexJS leverages the concept of replacing abstractions, if you
> create an XML and XMLList class in JavaScript and populate them with the
> same APIs as ActionScript, lots of things should work. The FalconJX
> compiler could easily be taught to convert “a..child” into
> “a.descendants()”. If the JS version has an extra filter() function, then
> FalconJX would convert
>
> a..grandchild.(@attr2 == 'fish’)
>
> into
>
> a.descendants().filter(function (node) { return
> node.attribute(‘fish’).length() })
>
> or something like that.
>
> I think the part of XML in ActionScript that isn’t practical to do in
> JavaScript is handling change notifications. It might be possible to do
> some of it for known properties but I think it would be fragile.
>
> For example:
>
> var d:XML = a..child[0];
> d.foo = <bar />;
>
> In ActionScript you can get a change notification when foo is assigned.
> With a bunch of work, if we know you are setting “foo” (which we do know
> in this case) I think we could use Object.defineProperty to define a
> property on d.
>
> What we can’t easily do is:
>
> var d:XML = a..child[0];
> var s:String = “someRandomPropertyName”;
> d[s] = <bar />;
>
> If we don’t know what ’s’ is, we can’t define properties early on the XML
> node. I suppose with even more code we could generate code for that.
>
> BTW, for any sort of solution, we would have to know that “d” is XML and
> not Object and that would require more careful type handling in the code
> our customers write. If you have:
>
>
> public class MyClass extends EventDispatcher
> {
> public var someProp:XML;
> }
>
> Then in some other class you have:
>
> var instance:MyClass = new MyClass();
> instance.addEventListener(“someEvent”, myHandler);
>
> function myHandler(event:Event):void
> {
> event.target.someProp.foo = <newnode />;
> }
>
> We have lost the notion that someProp is XML and not Object because
> event.target is defined as Object and not MyClass. Folks will have to fix
> up their code to be:
>
> (event.target as MyClass).someProp.foo = <newnode />;
>
> Which won’t be much fun and if you miss one, you won’t get a compile error.
>
> FWIW, we could probably put in a warning if you forget () on “length”,
> again if we know that length is being access on an XML node and not Object.
>
> HTH,
> -Alex
>
>
