flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject [FALCONJX][FLEXJS] XML handling (was Re: [FlexJS] Back port)
Date Mon, 09 Nov 2015 23:28:58 GMT
Renaming the thread

On 11/9/15, 1:12 PM, "Harbs" <harbs.lists@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


Mime
View raw message