RE: [gosh] Compiler choice [was Goshhawk language choices and more]

[David Arno <da...@davidarno.org>]

> From: niel.drummond@googlemail.com [mailto:niel.drummond@googlemail.com]
On Behalf Of Niel Drummond
> Sent: 20 February 2012 07:45
>
> 1) Wait for falcon, projected stable release late 2012, early 2013. 
This to my mind is the most risky of your three options. We wait a year,
then maybe get a compiler, which will be of unknown quality and usability.
Then we'd have to start work on getting it to support MXML properly.

> 2) Write a cross-compiler for flex from scratch.
This is, IMO at least, the best of your three options. It will be tough, but
if enough people get involved then I see no reason why we couldn't achieve
it.

> 3) Port the SDK to haxe (or build a converter)
Tried that and gave it up as a bad idea. There are numerous problems with
this approach:
1. haXe doesn't support numerous aspects of AS3, such as custom namespaces,
E4X, global functions and internal and private namespaces.  Porting Flex to
haXe would be a non-trivial task.
2. haXe compiles everything from source files. It has no support for
partially compiled library files. Whilst it is fast for small numbers of
files, this really doesn't scale well for larger applications, such as those
using the Flex SDK. From the tests I did, I estimated that needing to
recompile the SDK source files every time one did an application build would
add 1 - 2 minutes to the build.
3. The SDK wouldn't just need porting to haXe, it would need rewriting to
add lots of conditional compilation directives to it to control how it built
to SWFs and to JavaScript.

haXe is a great little hacking language (though don't call it that or indeed
a toy language in front of Nicolas Cannasse, as he took offense when I -in
my subtle-as-a-brick fashion - referred to it as the latter,) with a great
community around it. It just isn't the sort of thing I like to offer up to
an enterprise-type customer who'd normally consider Flex solutions.

Of course it's worth wondering why no one except Michael Labriola is
considering the fourth option in all of this: stick with the existing mxmlc
and compc compilers. They may be slow, but they work and in theory we are
supposed to be getting the source for them straight away, not in a year's
time. Perhaps we should be putting more effort into investigating modifying
them to output JavaScript, Android and IoS native etc?

David.

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Martin Heidegger <mh...@leichtgewicht.at>]

Hello David,

The mxmlc will be the compiler as soon as its commited and stay that way 
until another approach is sufficient I suppose.

I think the Falcon as well as gosh are community approach. Like the 
various JavaScript engines were for FireFox.
If someone is interested in the development of a Java, antlr, or for 
that matter haXe based compiler we should discuss how
we get those approaches on rail. I don't see a point in discussing the 
possibility without trying. Complex concepts such as
the full mxmlc just take a while to develop and get ready. Putting a 
timeline on any of it without tests or code to talk seems
tiring.

yours
Martin.

RE: [gosh] Compiler choice [was Goshhawk language choices and more]

[Gordon Smith <go...@adobe.com>]

> At Adobe, every single Flex public property, method and class had to be approved by the architectual review board which oversees the Flash API.

This is also true of 'protected' ones.

- Gordon Smith, Adobe (member of the Platform Architectural Review Board)


-----Original Message-----
From: Carol Frampton [mailto:cframpto@adobe.com] 
Sent: Wednesday, February 22, 2012 9:04 AM
To: flex-dev@incubator.apache.org
Subject: Re: [gosh] Compiler choice [was Goshhawk language choices and more]

>
>
>
>> In my experience, the mx_internal namespace was used often for the 
>> purposes such as to cover the weak points in design. I think that the 
>> problem of not documenting things could've been solved by @private

At Adobe, every single Flex public property, method and class had to be approved by the architectual review board which oversees the Flash API.
Once public, it can't be removed from the API since that could break user code.  From my experience, the tendency of the review board is to keep things simple and try to maintain consistency across the classes. For example, an substantial amount of time was spent on property, method and parameter names. 

mx_internal was sometimes used by if you thought something should be public but couldn't justify it to the review board so you left a back-door.  Sometimes mx_internal was used to cover "weak points in design".  I think the older code uses mx_internal much more than the newer code and some engineers use it more than others.

Carol

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Left Right <ol...@gmail.com>]

Carol, think of any number between 1 and 100, and I will find that number
of public or protected properties or methods that have not been documented,
and, instead were using @private ASDoc comment.
Ideally, that might have been as you describe it, but in practice it was
very far from that. (I only need to think of a grep or sed that would do
that :D)

> Substantial amount of time was spent on ... names.
Not trying to be sarcastic, but names like TreeDataDescriptor2 don't really
fall under "well thought through" category. But that's quire rare (there
are only about 5 or so classes that end with "2" in the framework).
ArrayCollection, which is not a collection per se, is way more severe.

Besides, I gave a particular example, where mx_internal was used to cover
poor design - there is a simple, efficient generic solution to replace it -
save objects into a dictionary, and you don't need to add a property to
keep their id on them.
Another example - all sorts of controls containing inner controls, such as,
for example, numeric stepper, text area and so on, which contain a text
field would use some mx_internal::textField to access the text field, and
you would run up the wall trying to understand where do the values comes
from, if you extended the control.
It was also some times used as "public Morozov" anti-pattern :) this one is
named after a
http://jamesdolan.blogspot.com/2011/05/pavlik-morozov-anti-pattern.htmli.e.
when the originally protected field would be exposed outside in the
inheriting class.

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Carol Frampton <cf...@adobe.com>]

>
>
>
>> In my experience, the mx_internal namespace was used often for the
>> purposes such as to cover the weak points in design. I think that the
>> problem of not documenting things could've been solved by @private

At Adobe, every single Flex public property, method and class had to be
approved by the architectual review board which oversees the Flash API.
Once public, it can't be removed from the API since that could break user
code.  From my experience, the tendency of the review board is to keep
things simple and try to maintain consistency across the classes. For
example, an substantial amount of time was spent on property, method and
parameter names. 

mx_internal was sometimes used by if you thought something should be
public but couldn't justify it to the review board so you left a
back-door.  Sometimes mx_internal was used to cover "weak points in
design".  I think the older code uses mx_internal much more than the newer
code and some engineers use it more than others.

Carol

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Jeffry Houser <je...@dot-com-it.com>]

On 2/20/2012 12:00 PM, Left Right wrote:
> I was actually under impression that Adobe will be committing code to 
> the compiler and / or framework developed here - that was at least my 
> understanding of the last whitepaper posted by Adobe, or am I 
> misunderstanding it? Maybe the word "support" isn't the best choice 
> though.
  I am under the same impression.  Writing code, contributing code, and 
supporting code are radically different things.

> In my experience, the mx_internal namespace was used often for the 
> purposes such as to cover the weak points in design. I think that the 
> problem of not documenting things could've been solved by @private

  Things marked as @private in ASDocs still show up in code hinting if 
appropriate.  Stuff in mx_internal did not.
  Is there metadata to prevent stuff from showing up in code hinting?



-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Left Right <ol...@gmail.com>]

I was actually under impression that Adobe will be committing code to the
compiler and / or framework developed here - that was at least my
understanding of the last whitepaper posted by Adobe, or am I
misunderstanding it? Maybe the word "support" isn't the best choice though.

In my experience, the mx_internal namespace was used often for the purposes
such as to cover the weak points in design. For instance, have you tried to
implement some sort of collection-view interface and extended Proxy, you
would've known that the framework code insists on the objects inside the
collection have mx_internal:uid or even mx_internal_uid property :) I think
that the problem of not documenting things could've been solved by @private
ASDoc meta (and it was indeed used all over the place) and it won't be
particularly difficult to have that sort of comment / annotation in HaXe
source code to show that the API is experimental. So, I think that this is
a non-issue.

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Jeffry Houser <je...@dot-com-it.com>]

On 2/20/2012 11:00 AM, Left Right wrote:
> I never found any practical use case that justified the use of internal or
> custom namespaces
  The Flex Framework uses a custom namespace (mx_internal) all over the 
place.  I believe the use case is "we need to expose this stuff so our 
code works, but don't have time to document it."
  You could say that is a cop out, which is fair.  But, it is also often 
a development reality when given timeline and budgets.  I expect that 
Apache may run into similar issues when we start doing releases.


> 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.
     I was under the impression Adobe would not be supporting any 
compilers coming out of the Apache project.



-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Left Right <ol...@gmail.com>]

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

RE: [gosh] Compiler choice [was Goshhawk language choices and more]

[Omar Gonzalez <om...@gmail.com>]

On Feb 20, 2012 7:08 AM, "David Arno" <da...@davidarno.org> wrote:
>
> > From: niel.drummond@googlemail.com [mailto:niel.drummond@googlemail.com]
> On Behalf Of Niel Drummond
> > Sent: 20 February 2012 07:45
> >
> > 1) Wait for falcon, projected stable release late 2012, early 2013.
> This to my mind is the most risky of your three options. We wait a year,
> then maybe get a compiler, which will be of unknown quality and usability.
> Then we'd have to start work on getting it to support MXML properly.
>
Just wanted to point out here that according to Gordon Smith, I believe,
the statement that we would have to deal with MXML in the compiler post
donation is incorrect as they already have built support for MXML with a
different approach than what we have in mxmlc. Im not saying its either the
right approach or 100% complete, just that it exists according to Adobe
folk.

--
Omar Gonzalez
s9tpepper@apache.org

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Left Right <ol...@gmail.com>]

Technically, any editor should, if you do `use namespace mx_internal` :) I
can remember that FD ignored the [Exclude] metadata - that's for sure. In
any case, the fact that it's not in the autocompletion is a side effect,
probably due to the editors not handling all of the AS3 syntax properly. I
think that this meta has also some effect on the way SWC is compiled, but
then again, the editor may look into SWC in different ways, so it may or
may not find those fields / classes.

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Niel Drummond <ni...@grumpytoad.org>]

On Mon, Feb 20, 2012 at 8:04 PM, Jeffry Houser <je...@dot-com-it.com>wrote:

> On 2/20/2012 1:46 PM, Left Right wrote:
>
>> Jeffry, what code shows up in the editor really depends on the editor you
>> are using, that's not universal, and stuff in mx_internal may show as
>> well,
>>
>  Which code editor will show that stuff?


FWIW there is some work going into the haxe compiler to hide public methods
from haxe's compilation daemon, which is used by IDE's to provide
autocompletion..

- Niel


>
>  if you wanted it to. However, Flash Builder also used various metadata to
>> hide either specific methods or entire classes (usually generated) from
>> documentation / autocompletion. [Exclude] and [ExcludeClass] would be what
>> I can remember right away, could be there were more.
>>
>  I believe it was the exclude metadata I was thinking of.  I didn't
> realize exclude had any relation to ASDoc generation, though.
>
>
>
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
>
>

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Jeffry Houser <je...@dot-com-it.com>]

On 2/20/2012 1:46 PM, Left Right wrote:
> Jeffry, what code shows up in the editor really depends on the editor you
> are using, that's not universal, and stuff in mx_internal may show as well,
   Which code editor will show that stuff?

> if you wanted it to. However, Flash Builder also used various metadata to
> hide either specific methods or entire classes (usually generated) from
> documentation / autocompletion. [Exclude] and [ExcludeClass] would be what
> I can remember right away, could be there were more.
   I believe it was the exclude metadata I was thinking of.  I didn't 
realize exclude had any relation to ASDoc generation, though.


-- 
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Left Right <ol...@gmail.com>]

Jeffry, what code shows up in the editor really depends on the editor you
are using, that's not universal, and stuff in mx_internal may show as well,
if you wanted it to. However, Flash Builder also used various metadata to
hide either specific methods or entire classes (usually generated) from
documentation / autocompletion. [Exclude] and [ExcludeClass] would be what
I can remember right away, could be there were more.

Re: [gosh] Compiler choice [was Goshhawk language choices and more]

[Niel Drummond <ni...@grumpytoad.org>]

On Mon, Feb 20, 2012 at 4:07 PM, David Arno <da...@davidarno.org> wrote:

> > From: niel.drummond@googlemail.com [mailto:niel.drummond@googlemail.com]
> On Behalf Of Niel Drummond
>

Thank you.


> > Sent: 20 February 2012 07:45
> >
> > 1) Wait for falcon, projected stable release late 2012, early 2013.
> This to my mind is the most risky of your three options. We wait a year,
> then maybe get a compiler, which will be of unknown quality and usability.
> Then we'd have to start work on getting it to support MXML properly.
>

I agree.


> > 2) Write a cross-compiler for flex from scratch.
> This is, IMO at least, the best of your three options. It will be tough,
> but
> if enough people get involved then I see no reason why we couldn't achieve
> it.
>

Maybe. The idea might be appealing, since it's always nicer to start with a
clean house. However, I think it will also take the longest time to
accomplish, and much of it is re-inventing the wheel. It takes time to
develop a stable compiler, it takes time to get cross-platform language
features ironed out in a conform way, it takes even more time to get all
the GUI features working in a stable way across runtimes.

Many of these stumbling blocks were dealt with by the haxe compiler, and
what I personally feel the haxe community can bring to the flex community,
is a general experience in making libraries work on other runtimes.


> > 3) Port the SDK to haxe (or build a converter)
> Tried that and gave it up as a bad idea. There are numerous problems with
> this approach:
> 1. haXe doesn't support numerous aspects of AS3, such as custom namespaces,
> E4X, global functions and internal and private namespaces.  Porting Flex to
> haXe would be a non-trivial task.
>

Writing a compiler is even less trivial.

For the 95 percentile, porting AS3 to haxe is trivial. I have ported large
and complex AS3 libraries (25-30K LOC) to haxe in a matter of weeks, other
haxe community members have too.

Some of those exclusive AS3 features you mention could be
emulated/implemented using haxe's macro feature. I would be surprised if
you said not having global functions is a blocker.

The biggest problem mentioned is e4X. Though, if you were to write your own
compiler and insist upon e4X, you would need to implement e4X in javascript
for non-mozilla browsers, which I think is quite a bit harder to get right
in a performant way than to take a step back, and think about a more
cross-target solution.


2. haXe compiles everything from source files. It has no support for
> partially compiled library files. Whilst it is fast for small numbers of
> files, this really doesn't scale well for larger applications, such as
> those
> using the Flex SDK. From the tests I did, I estimated that needing to
> recompile the SDK source files every time one did an application build
> would
> add 1 - 2 minutes to the build.
>

haxe supports swc files, there are a number of projects that can combine
these (hxswfml, samhaxe, swfmill) which in my mind is what is meant by
flash modularity (though, I admit, I only use flash to port it to
javascript).

If you use your own compiler or falconjs, you would still need to implement
your own javascript modularity functionality. In comparison, some recent
haxe code can read swf files to pull assets out, I'm not sure what could be
done about code.

Regarding compile speed, the compiler is fast, if you are invoking the
compiler more than once, then there is something wrong your project setup.
The exception to this is macro heavy code, which invokes the neko
interpreter during a compile phase and is noticeably slower.

3. The SDK wouldn't just need porting to haXe, it would need rewriting to
> add lots of conditional compilation directives to it to control how it
> built
> to SWFs and to JavaScript.
>

Code conditionals are generally used at a package level, you can avoid it
altogether by simply redirecting a package subtree to another one at
compile time, depending on the target (this is what jeash does).


> haXe is a great little hacking language (though don't call it that or
> indeed
> a toy language in front of Nicolas Cannasse, as he took offense when I -in
> my subtle-as-a-brick fashion - referred to it as the latter,) with a great
> community around it. It just isn't the sort of thing I like to offer up to
> an enterprise-type customer who'd normally consider Flex solutions.
>
>
Of course, but that's all very political, and IMHO ignores proven technical
advantages, time-to-market considerations, and the fact that you still have
to convince your clients that your new compiler is better than adobe's one
too.

- Niel



> Of course it's worth wondering why no one except Michael Labriola is
> considering the fourth option in all of this: stick with the existing mxmlc
> and compc compilers. They may be slow, but they work and in theory we are
> supposed to be getting the source for them straight away, not in a year's
> time. Perhaps we should be putting more effort into investigating modifying
> them to output JavaScript, Android and IoS native etc?


> David.
>
>