flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wasilewski <devudes...@gmail.com>
Subject Re: [FalconJS] concepts
Date Wed, 28 Nov 2012 21:35:13 GMT
Ok, both test are up to date including HaXe.

*Test of creation of this little structure*

*Test of speed of accession already created objects*

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 ;)

//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

//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 

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"


// to see if all Classes in the chain has been invoked on constructor in the correct order;

undefined, as expected, private field not accessible
my name is Bond
James Bond

// All good here

**//adobe.js* I took only essence of it and renamed adobe to mod.


//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.
my name is Bond


Same scenario like for other tests but I need to mention one thing here.


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 :)



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.


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
It can only grow exponentially to the scale of your project.


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" <devudesign@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message