Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <50B5052E.6000301@gmail.com>
References: 
 <CAJs+wW10J6cuNG+vfj33ZNofq+79VZcJP1rVoDF63ejpZ3r-wg@mail.gmail.com>
	<CCD91FE7.49088%aharui@adobe.com>
	<CAJs+wW1O9gh7eTQTR-AsTQyUE4O6JSLpYL+dZqXV+E=fQaio=w@mail.gmail.com>
	<50B4E8C3.5040201@gmail.com>
	<CAJs+wW2iu5UEJFjyO1+1BnV_+nMi93mnen84AJ1pE8PbCtFm-A@mail.gmail.com>
	<50B5052E.6000301@gmail.com>
Date: Tue, 27 Nov 2012 20:46:53 +0100
Message-ID: 
 <CAJs+wW29ccd1zkXhvXM667b3FY3q_pCYfo4j3rNQJ2GpuTonRg@mail.gmail.com>
Subject: Re: FalconJS has landed
From: Erik de Bruin <erik@ixsoftware.nl>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

One more thought (yes, I really can't help myself):

Google chose to go with closures (obviously), and I'm sure they care
about all the stuff you mention... And I'd say they have some
experience with building and maintaining large javascript projects. As
does Yahoo (YUI), jQuery and I'm sure others as well. They most likely
did their due diligence before choosing this technique over the
others, something we could benefit from.

A good place - albeit a bit random - to start reading about the
benefits of the approach I am advocating is:

http://www.examplejs.com/?p=250

Ok, I'll shut up now ;-)

EdB


On Tue, Nov 27, 2012 at 7:23 PM, Daniel Wasilewski <devudesign@gmail.com> wrote:
> Erik,
>
> If you don't care about memory consumption, output file size, long prototype
> chain, inheritance, slow downs on bigger structures than 1 plain objects...
> use it.
> Again, not saying let's prefer or favour one of the method over another,
> those things keeps changing over the time.
> This test just 2 years ago would be a different picture.
>
> All I am saying is to have ability to control he output of grammar of JS. I
> know my English is not perfect but that's my only point i am trying to make.
> If you feel it's endless... sorry. It wasn't my intention to make it long.
> But rather invite to constructive discussion. It is easy to say NO to
> solution I think doesn't suits me without giving any reason.
>
> I would like to hear about pros of module pattern myself. Prove me wrong, I
> will shout up :)
> I am not JS expert. But let's not make design decisions based on the latests
> trends, but technical reasoning.
>
> Dan
>
>
> On 11/27/2012 4:38 PM, Erik de Bruin wrote:
>>
>> Dan,
>>
>> This is my last comment on the subject, as I foresee another endless
>> discussion, but:
>>
>> Closure (Module Pattern) outperforms any other 'style' at least 2 to 1
>> on the test you quote, yet you recommend that we don't use it?
>>
>> EdB
>>
>>
>>
>> On Tue, Nov 27, 2012 at 5:22 PM, Daniel Wasilewski <devudesign@gmail.com>
>> wrote:
>>>
>>> I'll try to help Alex :)
>>> But he may correct me if I am wrong.
>>>
>>>
>>> I believe this little test will show full picture and all 4 common styles
>>> of
>>> JS programming we are talking about here.
>>>
>>> Notice there is nothing about inheritance, just plain objects (classes)
>>> Once inheritance is involved things are slowing down with different
>>> ratios.
>>>
>>> http://jsperf.com/closures-vs-objects-vs-object-literals-vs-prototype/2
>>>
>>> Current proposed style of JS output is Object Literal (red bar in that
>>> test);
>>> Prototype (green bar) in plain object test seems to be 2nd solution
>>> outperformed by closure (blue bar) these days.
>>>
>>> But when inheritance is involved blue bar is getting shorter and
>>> prototype
>>> is catching up.
>>> Prototype pattern has also less footprint, since you adding 1 shared
>>> behaviour to your object that will be reused wherever possible instead
>>> creating brand new object.
>>>
>>> There is no surprise why Closure style runs very well on web kit based
>>> browsers since Google promoting this style and making optimisation just
>>> for
>>> it.
>>> FireFox trying to catch up, but Safari seems to do well both.
>>>
>>>
>>> Here is a little example of inheritance done with prototype pattern
>>>
>>> var Class = function(){}; //empty function to avoid invocation during
>>>
>>> Function.prototype.extend = function(C){
>>>    Class.prototype = C.prototype;
>>>    this.prototype = new Class();
>>>    this.prototype.constructor = this;
>>>    return this.prototype
>>> };
>>>
>>> now you can easily do this:
>>>
>>> function EventDispatcher(){}
>>> p = EventDispatcher.prototype;
>>>
>>> function DisplayObject(){
>>>      EventDispatcher.call(this); //equivalent of super
>>> }
>>> p = DisplayObject.extend(EventDispatcher);
>>>
>>> THis is obviously simplified form of what is really needed but it is good
>>> enough to cover lots of aspects already.
>>> Don't want to repeat what has been already sent here as examples, but
>>> simplicity and speed of this solution will outperform anything in
>>> real-project-use-case-scenario.
>>>
>>> Dan
>>>
>>>
>>> On 11/27/2012 8:06 AM, Erik de Bruin wrote:
>>>>
>>>> Alex,
>>>>
>>>> You keep referring to a "prototype". I might be missing something.
>>>> Where can I find it/how do I run it?
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Mon, Nov 26, 2012 at 10:32 PM, Alex Harui <aharui@adobe.com> wrote:
>>>>
>>
>>
>


-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl