flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Wienberg <fr...@jangaroo.net>
Subject Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Date Mon, 21 Jan 2013 07:06:44 GMT
On Sun, Jan 20, 2013 at 11:28 PM, Michael Schmalle

> I think what my plan is, is to tell you I'm not going to ignore you, I'm
> focused on MXML just so I can get it into the flow. After I get it
> committed I will try and see what is going on with the code you wrote.

Totally fine.  While you are busy with MXML, I could spend my time getting
started with FalconJx and/or finishing the AS->JS Wiki page.

I am also pretty sure there are some others out there that may want to help
> out on something but the documentation on what we are doing is a but
> technical.
> Alex brought up a good point about the MXML and needing it soon, if I
> don't do it right now before we get head long into the finite part of the
> compiler, I'm going to end up resenting working on it. :)
> Actually, working on it today really gives me a sense of anticipation
> because MXML is one thing we have in our favor that could end up being
> something that can set this project apart and really allow for some
> interesting types of innovation. Who knows, we will keep that for the
> future.

Yes, MXML is something all languages-that-compile-to-JavaScript competitors
(TypeScript, Dart, Haxe, ...) currently lack!

> Along those lines, for now I don't see MXML as really a "class" one to
> one. It's more of and "intentional declaration of intent". Does that phrase
> make sense to you?

I guess you're talking about what I'd call an "object descriptor", like
ECMAScript 5 has the concept of "property descriptor" that is not the
actual property, but a descriptor to create a property. A class is
something quite similar to an object descriptor (because you have to
instantiate it to get an actual object). If I understand your point
correctly, MXML cannot create arbitrary classes (well, I guess it can
through <mx:Script> elements, but that's kind of dirty), but limits itself
to the declarative part, i.e. defining properties and instantiating and
wiring other objects through their properties. Right?
Another way to view MXML is as an "object serialization" format. Although
MXML is not used to store objects, serialization also focuses on object
properties, not their methods / behavior. Behavior is added (through
classes) on deserialization.

-Frank- J8)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message