Re: Adobe / Apache / Spoon Flex Tour

[Ariel Jakobovits]

I like this mysterious person. :)

I am starting to understand what he is pointing out as the shortcomings of mxml 
as implemented, I remember noticing these when first starting out but forgot as 
I focused on using what was available.

And i agree about language choice, using the best language for the job gives us 
the best chance to make advancements. Well, I have one reason we might want to 
use Java...if no one who is interested in working on the compiler wants to 
write it in anything else...so, question is, what do our most experienced and 
committed compiler developers prefer to use? Don't want to alienate them lest 
we be left with a great language for writing compilers and no compiler 
developers.

On Feb 19, 2012, at 4:03 AM, Left Right <olegsivo...@gmail.com> wrote:

> Roland:
> At the time I did some poking around MXML parser and code generation, I
> can't claim myself to be an expert on the issue, but I know some. So,
> here's my view of the situation: you say it works in Intellij, I say it's
> pretty much broken. Here's why: possibly, you only used the features you
> encountered in manuals Adobe put online, and you used them the way Adobe
> wrote them. I, on the contrary, was looking to reduce the code generation
> bloat, and was looking to do it the way the compiler can still handle, but,
> it might look less common. For example, you would do:
> 
> <mx:Script><![CDATA[ private function clickHandler():void { trace("hi!"); }
> <mx:Button click="clickHandler()"/>
> 
> I would do:
> 
> <mx:Button><mx:click>trace("hi");</mx:click></mx:Button>
> 
> There are many other examples, I don't want to bloat this thread.
> 
> Particular plaque in Intellij is debugging MXML - the debugger is not smart
> enough to understand what generated AS file is derived from what MXML, so
> no breakpoints for you in MXML files most of the time.
> 
> Intellij AS3 parser only understands about 90% of AS3, thus, for example {
> (true.valueOf()) : false } would be highlighted as an error, yet it's a
> valid AS3. It's MXML parser was based on some hardcoded tables, thus, the
> projects I worked on were usually painted in all red (the color to
> highlight a syntax error :)).
> 
> Re' MXML - it ultimately cannot handle constants - stupid design, sorry. It
> generates bindings for constants as if they were variables. The major fault
> in the design is that the authors decided to remove quotes from around
> string values in attributes. I'll explain.
> 
> If it was <foo stringProperty="'stringValue'"/>, then you could've made
> constant expression simply by copying whatever's in between the first and
> the last quote, but if you do <foo stringProperty="stringValue"/> - there's
> no way to tell, whether stringValue is a reference to some definition by
> the name stringValue or is it a literal string spelled "stringValue". This
> design flow resulted in tons of ad hoc code in MXMLC to resolve this
> ambiguity. It actually never cared to be systematic, thus, for example, in
> certain cases function references may not need binding braces, but in other
> situations they do and so on. It's pretty random and unsystematic.
> There are other rules enforced by MXML, that lack any kind of common sense
> - it must use some namespace from a variety defined in... bah, compiler
> source code! how's that? :) You cannot access a property of a read-only
> property - why? - no reason, just so you'd ask. You cannot pass arguments
> to constructor - for the very same particular reason. You cannot define
> access modifier, again, why - you know that already, right? I could
> continue, but I'll keep some for the future :P
> 
> * * *
> 
> Languages: I thought I argued my case, but I'll try to explain again, the
> plugins and the "mothership" compiler need not to run inside the same
> runtime - there is a traditional way to make programs cooperate - pipes,
> stream, well, you know. This is called modular architecture, or, if you
> like that Unix-like approach. Even if Java is widely used, this doesn't
> mean it's widely liked. WinAPI are a chore, but you cannot avoid it,
> because, in the end of the day, most software in the world runs on top of
> this crap. What I'm saying is that, for once, you are given a chance to do
> things properly! :) Learning new languages? - pew! if it's a good language,
> then why not? Besides, I think I said that people who would get seriously
> involved with the compiler aren't your average $10/hour freelancers, they
> might actually know some stuff about language design, and, almost
> certainly, Java won't be the language of choice for them :) Besides, those
> languages are cool, no, seriously, if you indeed like programming, you
> enjoy writing and perfecting the code written in them, unlike this kind
> of... masterpiece http://govnokod.ru/8865 (the piece of the code in the
> quote remained like that since before Adobe took over Macromedia, it's the
> remains of the rewrite of Macromedia old compiler, probably written in C++).
> But not only they are cool - they are in many respects a better tool for
> the job, they can do certain things pertaining to specific to compiler
> tasks way better then Java will ever possibly do. One more important thing
> - there are academic works and researches standing behind them, which are
> the bread and the air for someone who lives and breathes language design,
> compilers, computation etc. If you hope to invent, to advance, this would
> be the way to go.
> 
> * * *
> 
> Re' ANTLR - well, as I said, it's a tool for generating parsers for certain
> types of grammars, namely LR(1), or, to rephrase it, for LR(k) grammars,
> which can be made into LR(1) - this implies AS3 must be an LR(k) grammar.
> This, in other words, means that AS3 must be a deterministic, context-free
> language, yet it seems to me that it is not. For example, depending on the
> context square brackets may be interpreted as metadata or array (there are
> places, where compiler actually makes an arbitrary decision as of today),
> semicolon... I hate to say that, but it would be so much easier, if it was
> mandatory... it was soooooo stupid to make it optional... anyways.
> So, what I'm saying is - it is highly possible that ANTLR, or any other LR
> parser generator simply won't do the job because such job cannot be done by
> this kind of programs. There may not be an alternative, but to handcode the
> parser, or give up on certain language features to fit it into LR(1)
> grammar.
> 
> * * *
> 
> One more thing I forgot to mention before, with regard to MXMLC, the whole
> block dedicated to backing up the framework code, all the junk files like
> FlexInit, SystemManager, _global and so on - this should be clearly kept
> away from the compiler. It's insane it was made this way to begin with :)
> At the time, I was thinking of a separate module to compiler, responsible
> for AS3 source generation based on plain text templates. What I actually
> ended up doing - using PHP as source code generator, however, having a
> compiler module that could not only generate source by string replace, but,
> actually analyze the code would be certainly better. Still, I'd rather it
> be based on plain text templates then hardcoded into compiler itself. This
> holds true for resource bundles generation, all kinds of -services configs
> etc.
> 
> Mansour Blanco, you actually don't need XSLT, MXML is built on top of
> Velocity, a monstrous beast that can do all kinds of tricks, handling loops
> being not even a particularly remarkable one of them ;)
> 
> Best.
> 
> wvxvw