Frank,
Let me be direct, do you want to start working on AMD output?
IMO you should definitely finish up the Wiki stuff so it clear what
needs to be done with AMD output.
Your MXML interpretation is the way I would see it as well. It's
crystallized until invoked. That is what I meant by intention, it's
not a true class template until it has been deserialized by the
compiler.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
On Sun, Jan 20, 2013 at 11:28 PM, Michael Schmalle
<apa...@teotigraphix.com>wrote:
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)
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
