No no, don't shout up :) keep going.
I have read the article provided by you carefully.
If you will copy and paste it, and prepare a little function to
find/replace this sentence
"The simplest way to create a module in JavaScript is to use an *object
literal"* with "*prototype*"
The rest of above that sentence seems to be perfect.
Anything below is just a consequence of statement.
In JS word you will find bunch of old school JScripters they will
advocate and stands for the one thing:
Why on earth language that have a 'globals' concept needs a Singleton
pattern? The only thing/feature that can come to mind of proper OOP
language developer like C#, Java, AS3 is safety. We understand a concept
of public, final, abstract, private, protected. When writing API for
others to reuse it is even more important to use all advantage of those
languages. How many times in AS3 we using abstract or singleton
regardless of lack of native support? Because we do understand
importance of strict and structured language in rapid development.
However, when comes to FalconJS the task is to use strict proper OOP
language like AS3 to translate into JS. In my humble opinion, this is
what is all about, to protect us and give us more robust development
environment and target the platform we need without writing FOR the
platform. The fact that we are using AS3, output doesn't need to
leverage all those concepts on the target level at all. Even if the
output code would be set of plain objects or procedural style chain of
objects, if better for performance and the final result, better for
everyone. Good for marketing Apache Flex JS as the robust environment,
web RIA development environment.
P.S.
I took a break after my previous email, but I will definitely do some
JSperf test for tomorrow with inheritance, to show a full picture.
Dan
On 11/27/2012 7:46 PM, Erik de Bruin wrote:
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 <devudes...@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 <devudes...@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 <aha...@adobe.com> wrote:
