You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Michael Schmalle <ap...@teotigraphix.com> on 2013/02/07 21:53:09 UTC
[FalconJx] AMD production update inheritence
Hi,
Well here is another update, I pretty much have subclasses working
fine. There are still a couple issues that I will need to work out.
Like the $static on static methods I asked Frank about, haven't got a
reply.
There has been a couple things come up in the interum with me that I
might have to attend to, I haven't committed this code yet because I
want it pretty much "working" before I leave it.
I hope I can get time to work more on this but as I said, there are
some things I have to deal with.
Frank, let me know if you see any mistakes, interfaces are being
produced as well.
Does it matter if the public fields get initialized before the super call?
Mike
---------------------------------
AS
package com.acme {
import com.acme.sub.IOther;
import com.acme.sub.ISub;
public class B extends A implements IOther, ISub {
public static function nowPlusOne() {
return new Date(B.now.getTime() + 60*60*1000);
}
public function B(msg, count) {
super(msg);
this.count = count;
trace("now: " + B.now);
}
public var count = 0;
public var barfoo = A.bar(3);
public override function foo(x) {
return super.foo(x + 2) + "-sub";
}
public static var now = new Date();
}
}
---------------------------------
JS
define(["exports","runtime/AS3","classes/com/acme/A",
"classes/com/acme/sub/IOther","classes/com/acme/sub/ISub",
"classes/trace"], function($exports,AS3,A,IOther,ISub,trace) {
"use strict";
AS3.compilationUnit($exports, function($primaryDeclaration){
function B(msg, count) {
this.barfoo = (A._ || A._$get()).bar(3);
Super.call(this, msg);
count = count;
trace("now: " + B.now);
}
var Super = (A._ || A._$get());
var super$ = Super.prototype;
$primaryDeclaration(AS3.class_({
package_: "com.acme",
class_: "B",
extends_: Super,
implements_: [
IOther,
ISub
],
members: {
constructor: B,
count: {
value:0,
writable:true
},
foo: function foo(x) {
return this.foo$2(x + 2) + "-sub";
}
foo$2: super$.foo
},
staticMembers: {
nowPlusOne: function nowPlusOne() {
return new Date(B.now.getTime() + 60 * 60 * 1000);
}
}
}));
B.now = new Date();
});
});
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD production update inheritence
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Feb 7, 2013 at 11:33 PM, Frank Wienberg <fr...@jangaroo.net> wrote:
> When writing the Wiki page, I tried out how Flash / mxmlc handle field
> initializers (remember, there is no language spec), and to my surprise
> found
> out that non-static field initializer code gets evaluated *before* the
> super call
> and can't use "this". I did this wrong all the time in Jangaroo and didn't
> fix it
> yet, so the correct order in the JS prototype got wrong on the last commit
> when using the Jangaroo-generated code. Sorry for that.
>
>
Just fixed this in the as-js-runtime-prototype git repo!
Re: [FalconJx] AMD production update inheritence
Posted by Frank Wienberg <fr...@jangaroo.net>.
Mike, world peace is missing, please fix! :)
Re: [FalconJx] AMD production update inheritence
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Ok,
A lot of this stuff sometimes I "don't" get right off that bat. I'm
getting back into js, which is a good thing. :) So this issues, I just
don't quite understand at the moment but I don't need to either. ;-)
I will leave it up to you to say, Mike "this is missing, fix it" type
stuff, then everything works really quickly. :)
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
>>
>> BTW, my question about native was wrong, you had already answered why you
>> use native, I MEANT to ask why you took the !native calls out
>
>
> Ha, funny that was the only thing I *didn't* answer :-)
> But my explanation of why use "native!" anyway hints at why I took it out
> for some classes, so there is an additional rule:
> If the global JavaScript object is top-level (not a property of a
> "package"/namespace object) *and* it is not aliased *and* not "polyfilled",
> I though defining a local variable with the same name wouldn't make sense.
> This holds true for example for "String" and "parseInt".
>
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD production update inheritence
Posted by Frank Wienberg <fr...@jangaroo.net>.
>
> BTW, my question about native was wrong, you had already answered why you
> use native, I MEANT to ask why you took the !native calls out
Ha, funny that was the only thing I *didn't* answer :-)
But my explanation of why use "native!" anyway hints at why I took it out
for some classes, so there is an additional rule:
If the global JavaScript object is top-level (not a property of a
"package"/namespace object) *and* it is not aliased *and* not "polyfilled",
I though defining a local variable with the same name wouldn't make sense.
This holds true for example for "String" and "parseInt".
-Frank-
Re: [FalconJx] AMD production update inheritence
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Ah yeah, the 'this' was actually working fine, I changed something
right before I posted this and forgot to run the unit tests, when I
ran them again I had 2 failed tests.
The comma is fixed, minor... :)
BTW, I am using this project as an initial unit test structure because
it has all the aspects like you said so I have to figure out where the
code is going to be since I want it part of the suite.
I test each member;
@Test
public void test_secret()
{
IFunctionNode vnode = findFunction("secret", classNode);
visitor.visitFunction(vnode);
assertOut("secret$1: function secret(n) {\n\treturn this.msg + n;\n}");
}
I am still feeling like we are going to need a lot deeper tests with
expressions but I am not going to worry about that since it's trivial
really. Just work..
BTW, my question about native was wrong, you had already answered why
you use native, I MEANT to ask why you took the !native calls out. I
managed to get the compiler flagging native calls so we could use that
again eventually if you need it.
So sorry to have you write another couple paragraphs on what you
already wrote. ;-)
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Mike, this is (attention, pun:) super!
>
> Like the $static on static methods I asked Frank about, haven't got a
>> reply.
>
>
> Got one now! :-)
>
> Does it matter if the public fields get initialized before the super call?
>
>
> When writing the Wiki page, I tried out how Flash / mxmlc handle field
> initializers (remember, there is no language spec), and to my surprise found
> out that non-static field initializer code gets evaluated *before* the
> super call
> and can't use "this". I did this wrong all the time in Jangaroo and didn't
> fix it
> yet, so the correct order in the JS prototype got wrong on the last commit
> when using the Jangaroo-generated code. Sorry for that.
> Does it matter? Well, Jangaroo worked fine for years implementing it
> incorrectly, but it worked well for us.
> I'd say for the sake of compatibility with "real" ActionScript, for
> FalconJx,
> let's do it like the original, so your code for "B" is perfect.
>
> Well, almost ;-), two minor glitches I was only able to spot by diffing:
>
> - constructor: "this." missing before first "count"
> - comma missing before "foo$2: super$foo"
>
>
> All this is taking shape so quickly, I'm really impressed!
>
> Greetings
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] AMD production update inheritence
Posted by Frank Wienberg <fr...@jangaroo.net>.
Mike, this is (attention, pun:) super!
Like the $static on static methods I asked Frank about, haven't got a
> reply.
Got one now! :-)
Does it matter if the public fields get initialized before the super call?
When writing the Wiki page, I tried out how Flash / mxmlc handle field
initializers (remember, there is no language spec), and to my surprise found
out that non-static field initializer code gets evaluated *before* the
super call
and can't use "this". I did this wrong all the time in Jangaroo and didn't
fix it
yet, so the correct order in the JS prototype got wrong on the last commit
when using the Jangaroo-generated code. Sorry for that.
Does it matter? Well, Jangaroo worked fine for years implementing it
incorrectly, but it worked well for us.
I'd say for the sake of compatibility with "real" ActionScript, for
FalconJx,
let's do it like the original, so your code for "B" is perfect.
Well, almost ;-), two minor glitches I was only able to spot by diffing:
- constructor: "this." missing before first "count"
- comma missing before "foo$2: super$foo"
All this is taking shape so quickly, I'm really impressed!
Greetings
-Frank-