Looks like we'll have some fun debating which JS pattern to use.  In a five
minute drive-by of the Module Pattern, I found this [1].

I'm not advocating one pattern vs the other.  I'm still wondering why basic
object/prototype wasn't good enough.

The current FalconJS pattern is based on [2].  I'm still not clear why we
are not using it verbatim.  One of the interesting points of [2] is that it
doesn't fully run the constructors of the base classes when creating an
extension.

FalconJS will shove its output through Google Closure Compiler under the
right conditions.  I may have disabled it accidentally because I want to see
what the raw code looks like.

Couple of other thoughts:
A) We are translating code from a real class-based language to JS.  Lots of
JS patterns I take quick looks at seem to use lots of interesting
conventions, but they may not support all of the things we may come to
expect in the existing AS3 code bases we want to transcode, like "is" and
"instanceof".

B) Do we need to support truly separate compilation "units" for large
projects?  Minification seems to require that you have all of the JS you
will ever load available at minification time.  With AS, you could load just
about anything from anywhere at any time.

[1] http://snook.ca/archives/javascript/no-love-for-module-pattern
[2] http://ejohn.org/blog/simple-javascript-inheritance/


On 11/26/12 5:04 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:

> Ok, simple example implementation of the use of the Module Pattern in
> combination with the Google Closure Compiler can be found here:
> 
> https://www.ixsoftware.nl/apache-flex/falcon-poc/compile.php
> 
> It basically takes 2 "class" files, and puts them through the GCC
> (ADVANCED optimisation) and runs the resulting minimised JS to show
> functionality. I've provided links to the original JS at the top of
> the file, for easy access.
> 
> The GCC has some more features that might be nice for us to implement,
> but for now, I'll have a look at how I can get the FalconJS compiler
> to output code that might come close to what the above example uses as
> input.
> 
> EdB
> 
> 
> 
> On Mon, Nov 26, 2012 at 12:10 PM, Daniel Wasilewski
> <devudes...@gmail.com> wrote:
>> That's sounds promising. Having ability to specify grammar on output will
>> give Falcon a lot more horse power.
>> I was pointing at HaXe JS output as an example, because it is the best
>> (performance/footprint wise) out there.
>> 
>> However scope and chain of accessibility in JS slowing down a lot.
>> And they've decided to represent entire source structure exactly the way you
>> have your namesapces in that source.
>> Each link of this chain is represented as an Object. It sounds like a safe
>> solution to avoid clashes but it comes with a cost.
>> This is a biggest drawback of HaXe, but definitely something that can be
>> avoided.
>> 
>> There is another concept of extern classes that can be implemented directly
>> in the output and Compiler can map the code on architecture level.
>> Eventually inject missing bits directly into it. Does Falcon could be
>> adopted to this?
>> 
>> I wonder how Falcon will deal with a display list.
>> Is it going to be similar to the output of Edge? Or just Canvas based api?
>> 
>> I am having big hopes for Falcon as the only part of the hand-over process
>> to be honest.
>> And not necessarily in conjunction of flex but as a pure AS3 - JS evaluator.
>> 
>> Best
>> Dan
>> 
>> 
>> 
>> On 11/26/2012 10:48 AM, Erik de Bruin wrote:
>>> 
>>> Hi,
>>> 
>>> FYI, I'm working on an POC for using a Module Pattern combined with
>>> Google Closure annotations to get a Javascript class as close to AS3
>>> as I can get it. This might serve as a starting point for defining the
>>> FalconJS output.
>>> 
>>> EdB
>>> 
>>> 
>>> 
>>> On Sun, Nov 25, 2012 at 4:59 AM, Alex Harui <aha...@adobe.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 11/24/12 3:42 PM, "Daniel Wasilewski" <devudes...@gmail.com> wrote:
>>>> 
>>>>> And here is a little example of
>>>>> the very nature of this problem:
>>>>> 
>>>>> http://jsperf.com/object-create-with-object-literal-vs-prototype
>>>> 
>>>> I must be missing something, but I don't see where the output code calls
>>>> Object.create().
>>>>> 
>>>>> We don't know what future will bring, maybe they will go crazy and
>>>>> built-in jQuery interpreter in their browsers, or do more crazy
>>>>> things...
>>>>> I am not saying that current output is wrong, but did you consider
>>>>> different styles?
>>>> 
>>>> This is not my code or Gordon's.  Another engineer on another team put
>>>> this
>>>> together very quickly.  I just made it appear to work before donation.
>>>> We
>>>> have no way of knowing what he did or did not consider, all we know is
>>>> what
>>>> is in the code that was donated.
>>>>> 
>>>>> Or at least have a choice to spit out a code in the
>>>>> way you can configure, specify some rules of AST?.
>>>> 
>>>> I think you can change the code there, but I don't see any config options
>>>> other than it appears to be able to hook into Jquery.
>>>>> 
>>>>> Take a look at HaXe
>>>>> output for instance.
>>>>> 
>>>>> I don't care if the output code is ugly and messy. What I do care about,
>>>>> is that this very code is the best performer. I am writing AS3/Flex code
>>>>> for clarity and speed of production, and what I expect is the best
>>>>> performance on the other side. No more slow downs and bloated stuff.
>>>>> Because it will only tell people, pick one of the native JS framework if
>>>>> you need to develop RIA application for HTML5. The last thing Flex need
>>>>> is reputation of over-bloated stuff on the future platform of the web.
>>>>> Do this the best way, or do this well enough otherwise don't do it at
>>>>> all.
>>>> 
>>>> Well, that is all in our control now.  I will say that there is a good
>>>> chance that the final output won't be the absolute fastest as we are
>>>> translating from AS to JS so there is likely to be some impedance
>>>> mismatch
>>>> there.
>>>> 
>>>> For example, it appears that the current code has chosen a fancier
>>>> inheritance scheme than the bare bones object.prototype pattern,
>>>> potentially
>>>> to allow for class reflection kinds of stuff.  I'm not sure how much this
>>>> costs us and whether we truly have to have it.
>>>> 
>>>> I also noted the output code calls newObject in certain cases.  I'm not
>>>> sure
>>>> if that is done for object pooling or memory management or for some other
>>>> reason.  The adobe.js file I checked in was written by me and only has
>>>> enough code in it to make my demo run.  I have no idea how much other
>>>> infrastructure was actually behind those calls.
>>>> 
>>>>>>> 2. adobe.extend / adobe.classes? shouldn't be apache?
>>>>>> 
>>>>>> Well, it shouldn't be "adobe", but I'm not sure what we should change
>>>>>> it to.
>>>>> 
>>>>> If apache sounds too general maybe just flex? Keep in mind that
>>>>> apache.flex.classes will destroy performance a bit, yeap that's what JS
>>>>> is about, shallow water ;)
>>>> 
>>>> I left it as "adobe" until we argue over what to call it and make a
>>>> decision.
>>>>> 
>>>>> Dan
>>>> 
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>> 
>>> 
>>> 
>> 
> 
> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Reply via email to