Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olegsivokon@gmail.com
 designates 209.85.210.175 as permitted sender)
Received-SPF: pass (google.com: domain of olegsivokon@gmail.com designates
 10.43.44.69 as permitted sender) client-ip=10.43.44.69;
MIME-Version: 1.0
In-Reply-To: 
 <CAEFz_vsDrknQx2FwneoKuHm5nfES2hUABjvoJJz-dfzpVHuW5w@mail.gmail.com>
References: <00e501ccefe1$6467dc30$2d379490$@davidarno.org>
	<CAEFz_vsDrknQx2FwneoKuHm5nfES2hUABjvoJJz-dfzpVHuW5w@mail.gmail.com>
Date: Mon, 20 Feb 2012 18:00:05 +0200
Message-ID: 
 <CAJQBtgkHkvQYRGX01aWunww1jAHGntuE5e+mak9EJJ1sxHhs+A@mail.gmail.com>
Subject: Re: [gosh] Compiler choice [was Goshhawk language choices and more]
From: Left Right <olegsivokon@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=bcaec52e5f8945f37204b96763d9

--bcaec52e5f8945f37204b96763d9
Content-Type: text/plain; charset=ISO-8859-1

Well, HaXe can use pre-compiled code, since maybe more then a year ago I
guess... It doesn't use SWC, but ans SWF as an input is OK. Probably Niel
can elaborate on that, or correct me if I'm wrong.

HaXe has a way to deal with AS3 global functions (for example you could've
exposed them through Lib class), I don't think it would be particularly
difficult to add a compiler macros to handle the declaration of such
functions too, when working particularly on AS3 target.

I never found any practical use case that justified the use of internal or
custom namespaces except for some side effects, like, for example,
providing access to a function if the code asking for the access is
authorized to do it. Which was still a nice, but useless trick. I could
never be confident whether to use protected or private because I really
view them as the same thing. I really think that separation of these two
added more complication, where it wasn't actually needed.

I see the absence of E4X as a good thing, it has proved to be both very
difficult for understanding and inefficient, especially as implemented in
ASC/MXMLC. It is both difficult for the user to write, for the compiler to
optimize and for the editor to highlight it properly. Besides, the
instances of framework code using E4X can be counted on the fingers of one
hand, so it's not really an issue.

In my opinion, the framework in any case requires a very fundamental
rewrite. The way things were done wasn't good, but no one took the courage
to change that because of number of promises Adobe had to keep to the
people who used the framework.

Why not use MXMLC? - obviously, Adobe aren't going to support it, unless
for maybe critical fixes, so if you are going to support it, you are quite
on your own with that. MXMLC, as a program, suffers from all kinds of
architecture errors and this is probably the reason Adobe decided to not to
fix it, but develop something new.
When I used Metaas, I used it because me and my friend where trying to do
something like real-time code-behind generation for MXML files. I.e. we
were working on a plugin for FlashDevelop that would compile MXML files as
you edit them and, if you wanted to, you could switch to see the source
produced by MXMLC. While doing this, I got acquainted with MXMLC source
code more closely, and, honestly, it's a mess... After some time of trying
to do what we wanted with MXMLC, we decided to patch Metaas to do the
codegeneration, because it seemed to be easier and much more generic! We
actually succeeded to a degree the prototype was working :) But then we got
both frustrated about MXML as a concept and never touched that thing again.

Best.

wvxvw

--bcaec52e5f8945f37204b96763d9--