Ok, both test are up to date including HaXe.
*Test of creation of this little structure*
http://jsperf.com/inheritance-yet-another-test/3
*Test of speed of accession already created objects*
http://jsperf.com/inheritance-yet-another-test/4
Which confirms what I have said before, that is a best out there but not
the best possible ;)
There was also a functionality test for all of them, not unit test really ;)
*//Classic*
//Just a Java like setters/getters for backward compatibility
var instanceA = new MySubSubClassA();
//Having public variable when setter/getter pattern is not needed it
shouldn't even be there, but this is just a test
instanceA.setName("James");
//instead of using setter we assigned it directly to public variable to
see if you can omit setters for public variables
instanceA.surname = "Bond";
console.log(instanceA.name); //expected undefined, because it's a
private field and not accessible from outside of prototypal chain.
It makes it perfect for hiding internals when getter/setter patterns
applies.
console.log(instanceA.surname); //Bond, because it's public
console.log(instanceA.getSurname()); //"my name is Bond", because getter
has been overridden in subclass
console.log(instanceA.getFullName()); //"James Bond"
*
**Output*
-::constructed
--::constructed
---::constructed
// to see if all Classes in the chain has been invoked on constructor in the
correct order; Passed
undefined, as expected, private field not accessible
Bond
my name is Bond
James Bond
// All good here
*
**//adobe.js* I took only essence of it and renamed adobe to mod.
*Output
*
-::constructed
--::constructed
---::constructed
//super figured out, all good
James - it shouldn't be here! safety of module pattern fails ;)
It might not be considered as an issue since we don't really care about
safety of output.
Bond
my name is Bond
JamesBond
*HaXe*
Same scenario like for other tests but I need to mention one thing here.
*IMPORTANT:*
I took just $extend model of HaXe, there is much more going on in the final
output, also,
I kept the structure on the same level as the Main.hx class to avoid namespace
issue.
otherwise instead:
var instanceC = new MyExExClassC();
var instanceC = new com.apache.flex.MyExExClassC();
not to mention that you have massive bunch of objects represents entire tree of
your project like this:
var com = com || {}
if(!com.apache) com.apache = {}
if(!com.apache.flex) com.apache.flex = {}
com.apache.flex.MyClassC = function() {
};
com.apache.flex.MyClassC.__name__ = true;
com.apache.flex.MyClassC.prototype = {
setSurname: function(value) {
this.surname = value;
}
,getSurname: function() {
return this.surname;
}
,setName: function(value) {
this.name = value;
}
,getName: function() {
return this.name;
}
,__class__: com.apache.flex.MyClassC
}
That will slow down both test and I am sure adobe.js is the winner in this
situation.
This very little thing destroys performance of everything. JavaScript is a
shallow water friendly more than anything else.
And this very test does not represents real world example unless you crazy
enough and keep your all classes next to Main.hx a t all time :)
*Output*
---::constructed
--::constructed
-::constructed
Reverse order of instantiation..!? interesting
James - same issue aka adobe'js. It might not be considered as an issue since
we don't really care about safety of output.
Bond
my name is Bond
James Bond
this part is correct
So, please tell me why not to go the classic route as a very little overhaul
for the application that can be built on top of AS3/Flex?
This is bloody 3 classes with 4 methods in it, and we are not talking here
about few % but tens.
It can only grow exponentially to the scale of your project.
Dan
On 11/28/2012 8:26 PM, Markus Gritsch wrote:
Hi everyone,
Maybe someone can clarify the difference between haxe`s - as3-2-js output
target and falcon-js. Both are producing js code. Haxe supports a collection of
multiple output formats, too. Maybe the solution everyone is talking about is
already out there - have???
Thanks for your input
On Nov 28, 2012, at 9:04 PM, Alex Harui wrote:
On 11/28/12 12:01 PM, "Daniel Wasilewski" <devudes...@gmail.com> wrote:
Ok will try again by changing a subject because you seems to moved away
from original topic, and I don't want to interrupt :)
So far I have a test to compare very simple model of prototypal
inheritance and proposed module pattern that seems to be out of falconJS
compiler little syntactic sugar.
I have minimised this source a bit, there was few more additional fields
that I guess something is depends on but even striping it out:
http://jsperf.com/inheritance-yet-another-test/3
If you go to the revision 2 of this test, there will be different
comparison.
http://jsperf.com/inheritance-yet-another-test/3
Speed of accession of those objects.
However I would like to improve it, because adobe.js implementation
doesn't seems to call super as the classic does.
So it might be not relevant test right now. Does anybody know how to
call super from there?
It looks like in adobe.js around line 61 it tests to see if the super class
has the function and creates a _super function you can call.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
