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 2012/12/22 01:00:35 UTC
[FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Hi,
Well I busted my A$$ before I hit vacation, Erik you can look at
TestGoogEmiter and the JSGoogEmitter to see the black majik I whipped
up today.
Basically with the NEW FalconJx (BTW I'm starting to like this name
now, the "x" with Fle"X"), cross compiler is doing this all. I know
there are missing "this, super" etc etc etc, but this things is working!
And all that little stuff is easy to add now. Like I said in my
commits, I have package down to expressions working and it creates
valid AS3 source code from the AST.
Now it's just work filling in all the holes you have listed in the
as->js conversion table.
Frank, I'm sure you could look at my code and take the JSGoogEmitter
as an example and create a prototype JSRequireEmitter with the pattern
I have setup.
I'm still refactoring but it's looking good.
Peace and happy new year,
Mike
----------------------------------------------------------------------------
AS Code
package com.example.components
{
import org.apache.flex.html.staticControls.TextButton;
public class MyTextButton extends TextButton
{
public function MyTextButton()
{
if (foo() != 42) {
bar();
}
}
private var _privateVar:String = "do ";
public var publicProperty:Number = 100;
public function myFunction(value: String): String
{
return "Don't " + _privateVar + value;
}
}
}
----------------------------------------------------------------------------
JS Code
goog.provide('com.example.components.MyTextButton');
goog.require('org.apache.flex.html.staticControls.TextButton');
/**
* @constructor
*/
com.example.components.MyTextButton = function() {
if (foo() != 42) {
bar();
}
}
/**
* @type {String}
*/
com.example.components.MyTextButton.prototype._privateVar = "do ";
/**
* @type {Number}
*/
com.example.components.MyTextButton.prototype.publicProperty = 100;
/**
* @this {com.example.components.MyTextButton}
* @param {String} value
* @return {String}
*/
com.example.components.MyTextButton = function(value:String) {
return "Don't " + _privateVar + value;
}
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Posted by Daniel Wasilewski <de...@gmail.com>.
well, Christmas time, parents in law in house, perfect moment to have a
read trough then :)
Merry Christmas to everyone.
On 12/22/2012 12:09 AM, Michael Schmalle wrote:
> Nice catch;
>
> But as I said I wasn't done. :) What you see is that I am tired and
> stopping for today. :) I just wanted to post my progress.
>
>
> I didn't have time to override emitParameters() in ASEmitter to change
> how a parameter is emitted from AS3. Look at the source code and you
> will see what I am talking about.
>
> But thanks for reading. ;-)
>
>
> Mike
>
>
> Quoting Daniel Wasilewski <de...@gmail.com>:
>
>> well done Mike
>>
>> However JS output has some issues.
>>
>> |JSC_PARSE_ERROR: Parse error. missing ) after formal parameters at
>> line 29 character 52
>> com.example.components.MyTextButton = function(value:String) {
>> ^
>> JSC_PARSE_ERROR: Parse error. syntax error at line 31 character 0
>> }
>> ^|
>>
>> On 12/22/2012 12:00 AM, Michael Schmalle wrote:
>>> goog.provide('com.example.components.MyTextButton');
>>>
>>> goog.require('org.apache.flex.html.staticControls.TextButton');
>>>
>>> /**
>>> * @constructor
>>> */
>>> com.example.components.MyTextButton = function() {
>>> if (foo() != 42) {
>>> bar();
>>> }
>>> }
>>>
>>> /**
>>> * @type {String}
>>> */
>>> com.example.components.MyTextButton.prototype._privateVar = "do ";
>>>
>>> /**
>>> * @type {Number}
>>> */
>>> com.example.components.MyTextButton.prototype.publicProperty = 100;
>>>
>>> /**
>>> * @this {com.example.components.MyTextButton}
>>> * @param {String} value
>>> * @return {String}
>>> */
>>> com.example.components.MyTextButton = function(value:String) {
>>> return "Don't " + _privateVar + value;
>>> }
>>
>>
>
Re: [FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Nice catch;
But as I said I wasn't done. :) What you see is that I am tired and
stopping for today. :) I just wanted to post my progress.
I didn't have time to override emitParameters() in ASEmitter to change
how a parameter is emitted from AS3. Look at the source code and you
will see what I am talking about.
But thanks for reading. ;-)
Mike
Quoting Daniel Wasilewski <de...@gmail.com>:
> well done Mike
>
> However JS output has some issues.
>
> |JSC_PARSE_ERROR: Parse error. missing ) after formal parameters at
> line 29 character 52
> com.example.components.MyTextButton = function(value:String) {
> ^
> JSC_PARSE_ERROR: Parse error. syntax error at line 31 character 0
> }
> ^|
>
> On 12/22/2012 12:00 AM, Michael Schmalle wrote:
>> goog.provide('com.example.components.MyTextButton');
>>
>> goog.require('org.apache.flex.html.staticControls.TextButton');
>>
>> /**
>> * @constructor
>> */
>> com.example.components.MyTextButton = function() {
>> if (foo() != 42) {
>> bar();
>> }
>> }
>>
>> /**
>> * @type {String}
>> */
>> com.example.components.MyTextButton.prototype._privateVar = "do ";
>>
>> /**
>> * @type {Number}
>> */
>> com.example.components.MyTextButton.prototype.publicProperty = 100;
>>
>> /**
>> * @this {com.example.components.MyTextButton}
>> * @param {String} value
>> * @return {String}
>> */
>> com.example.components.MyTextButton = function(value:String) {
>> return "Don't " + _privateVar + value;
>> }
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Posted by Daniel Wasilewski <de...@gmail.com>.
well done Mike
However JS output has some issues.
|JSC_PARSE_ERROR: Parse error. missing ) after formal parameters at line
29 character 52
com.example.components.MyTextButton = function(value:String) {
^
JSC_PARSE_ERROR: Parse error. syntax error at line 31 character 0
}
^|
On 12/22/2012 12:00 AM, Michael Schmalle wrote:
> goog.provide('com.example.components.MyTextButton');
>
> goog.require('org.apache.flex.html.staticControls.TextButton');
>
> /**
> * @constructor
> */
> com.example.components.MyTextButton = function() {
> if (foo() != 42) {
> bar();
> }
> }
>
> /**
> * @type {String}
> */
> com.example.components.MyTextButton.prototype._privateVar = "do ";
>
> /**
> * @type {Number}
> */
> com.example.components.MyTextButton.prototype.publicProperty = 100;
>
> /**
> * @this {com.example.components.MyTextButton}
> * @param {String} value
> * @return {String}
> */
> com.example.components.MyTextButton = function(value:String) {
> return "Don't " + _privateVar + value;
> }
Re: [FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Oh you made me break my promise of radio silence! I guess that will
start tomorrow, my kids are throwing tomatoes at me then they get up
(I'm on EST). :)
Yes, The way I am testing this is have your debug workspace setup with
the variables view.
- Put your break point on visitor.visitFile(node); line which is #58
in that code.
- put your cursor on the testSimple() line #47 text
- hit F11 to debug
- step passed the visitFile() method 1 time
- look in the variables view, open "this" variable
- click on the "writer" variable and you will see the nicly output code.
You can do this for any of the myriad almost 200 tests we have now,
same process, that is how I debug this stuff.
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> FYI, I was able to use the unit test to look at the JS output, by
> uncommenting the assert and looking at it fail ;-)
>
> Is there a more convenient way to do this? Mind you, I'm not
> complaining! Just askin' ;-)
>
> EdB
>
>
>
> On Sat, Dec 22, 2012 at 9:37 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> Awesome, Mike!
>>
>> Now you've gone and created a reason for me to waste a considerable
>> amount of the holidays on getting to know this code and "finish" the
>> conversion table ;-)
>>
>> Have a very merry Xmas,
>>
>> EdB
>>
>>
>>
>> On Sat, Dec 22, 2012 at 1:00 AM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>>>
>>> Hi,
>>>
>>> Well I busted my A$$ before I hit vacation, Erik you can look at
>>> TestGoogEmiter and the JSGoogEmitter to see the black majik I whipped up
>>> today.
>>>
>>> Basically with the NEW FalconJx (BTW I'm starting to like this
>>> name now, the
>>> "x" with Fle"X"), cross compiler is doing this all. I know there
>>> are missing
>>> "this, super" etc etc etc, but this things is working!
>>>
>>> And all that little stuff is easy to add now. Like I said in my commits, I
>>> have package down to expressions working and it creates valid AS3 source
>>> code from the AST.
>>>
>>> Now it's just work filling in all the holes you have listed in the as->js
>>> conversion table.
>>>
>>> Frank, I'm sure you could look at my code and take the JSGoogEmitter as an
>>> example and create a prototype JSRequireEmitter with the pattern I have
>>> setup.
>>>
>>> I'm still refactoring but it's looking good.
>>>
>>> Peace and happy new year,
>>> Mike
>>>
>>>
>>> ----------------------------------------------------------------------------
>>> AS Code
>>>
>>> package com.example.components
>>> {
>>>
>>> import org.apache.flex.html.staticControls.TextButton;
>>>
>>> public class MyTextButton extends TextButton
>>> {
>>> public function MyTextButton()
>>> {
>>> if (foo() != 42) {
>>> bar();
>>> }
>>> }
>>>
>>> private var _privateVar:String = "do ";
>>>
>>> public var publicProperty:Number = 100;
>>>
>>> public function myFunction(value: String): String
>>> {
>>> return "Don't " + _privateVar + value;
>>> }
>>> }
>>> }
>>>
>>>
>>>
>>> ----------------------------------------------------------------------------
>>> JS Code
>>>
>>>
>>>
>>> goog.provide('com.example.components.MyTextButton');
>>>
>>> goog.require('org.apache.flex.html.staticControls.TextButton');
>>>
>>> /**
>>> * @constructor
>>> */
>>> com.example.components.MyTextButton = function() {
>>> if (foo() != 42) {
>>> bar();
>>> }
>>> }
>>>
>>> /**
>>> * @type {String}
>>> */
>>> com.example.components.MyTextButton.prototype._privateVar = "do ";
>>>
>>> /**
>>> * @type {Number}
>>> */
>>> com.example.components.MyTextButton.prototype.publicProperty = 100;
>>>
>>> /**
>>> * @this {com.example.components.MyTextButton}
>>> * @param {String} value
>>> * @return {String}
>>> */
>>> com.example.components.MyTextButton = function(value:String) {
>>> return "Don't " + _privateVar + value;
>>> }
>>>
>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Erik de Bruin <er...@ixsoftware.nl>.
FYI, I was able to use the unit test to look at the JS output, by
uncommenting the assert and looking at it fail ;-)
Is there a more convenient way to do this? Mind you, I'm not
complaining! Just askin' ;-)
EdB
On Sat, Dec 22, 2012 at 9:37 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Awesome, Mike!
>
> Now you've gone and created a reason for me to waste a considerable
> amount of the holidays on getting to know this code and "finish" the
> conversion table ;-)
>
> Have a very merry Xmas,
>
> EdB
>
>
>
> On Sat, Dec 22, 2012 at 1:00 AM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>>
>> Hi,
>>
>> Well I busted my A$$ before I hit vacation, Erik you can look at
>> TestGoogEmiter and the JSGoogEmitter to see the black majik I whipped up
>> today.
>>
>> Basically with the NEW FalconJx (BTW I'm starting to like this name now, the
>> "x" with Fle"X"), cross compiler is doing this all. I know there are missing
>> "this, super" etc etc etc, but this things is working!
>>
>> And all that little stuff is easy to add now. Like I said in my commits, I
>> have package down to expressions working and it creates valid AS3 source
>> code from the AST.
>>
>> Now it's just work filling in all the holes you have listed in the as->js
>> conversion table.
>>
>> Frank, I'm sure you could look at my code and take the JSGoogEmitter as an
>> example and create a prototype JSRequireEmitter with the pattern I have
>> setup.
>>
>> I'm still refactoring but it's looking good.
>>
>> Peace and happy new year,
>> Mike
>>
>>
>> ----------------------------------------------------------------------------
>> AS Code
>>
>> package com.example.components
>> {
>>
>> import org.apache.flex.html.staticControls.TextButton;
>>
>> public class MyTextButton extends TextButton
>> {
>> public function MyTextButton()
>> {
>> if (foo() != 42) {
>> bar();
>> }
>> }
>>
>> private var _privateVar:String = "do ";
>>
>> public var publicProperty:Number = 100;
>>
>> public function myFunction(value: String): String
>> {
>> return "Don't " + _privateVar + value;
>> }
>> }
>> }
>>
>>
>>
>> ----------------------------------------------------------------------------
>> JS Code
>>
>>
>>
>> goog.provide('com.example.components.MyTextButton');
>>
>> goog.require('org.apache.flex.html.staticControls.TextButton');
>>
>> /**
>> * @constructor
>> */
>> com.example.components.MyTextButton = function() {
>> if (foo() != 42) {
>> bar();
>> }
>> }
>>
>> /**
>> * @type {String}
>> */
>> com.example.components.MyTextButton.prototype._privateVar = "do ";
>>
>> /**
>> * @type {Number}
>> */
>> com.example.components.MyTextButton.prototype.publicProperty = 100;
>>
>> /**
>> * @this {com.example.components.MyTextButton}
>> * @param {String} value
>> * @return {String}
>> */
>> com.example.components.MyTextButton = function(value:String) {
>> return "Don't " + _privateVar + value;
>> }
>>
>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Well,
If you look at my commits, I already have this implemented in JSGoogEmitter.
From;
function method1(p1:int, p2:int, p3:int = 3, p4:int = 4):int{
return p1 + p2 + p3 + p4;
}
To;
foo.bar.A.method1 = function(p1, p2, p3, p4) {
if (arguments.length < 4) {
if (arguments.length < 3) {
p3 = 3;
}
p4 = 4;
}
return p1 + p2 + p3 + p4;
}
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> On Sun, Dec 23, 2012 at 11:32 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> My personal preference for optional arguments goes to:
>>
>> optArg = optArg !== 'undefined' ? optArg : defaultValue;
>>
>
> Hi Erik,
>
> the way we implement this should not change ActionScript language
> semantics. Sorry, but this is not a question of personal preference.
> As explained in detail in this blog
> post<http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html>,
> ActionScript does *not* replace undefined parameters by their default
> values, but it only uses the default values when less actual parameters are
> given in the call. Thus, the generated code has to check arguments.length.
> The blog post discusses some optimizations (performance, code size), but if
> you want a solution that is easy to generate (one default parameter => one
> line of generated code) *and* leads to the correct semantics, please use
>
> if (arguments.length < optArgIndex) optArg = defaultValue;
>
> I'm a big fan of ?: expressions, but in this case, an if-statement is
> clearly the better choice, as "else", the parameter value should stay as-is
> (and not be assigned to itself).
> Optimization: When there are multiple optional arguments, it is obvious
> that the corresponding if-statements should be sorted by decreasing
> argument index and then nested, because it is obsolete to check for
> arguments.length
> < 4 if you already know that arguments.length < 3. But I agree that we can
> add this optimization later. I just would like to see us get the
> *semantics*right in the first go.
>
> Greetings
> -Frank-
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Frank Wienberg <fr...@jangaroo.net>.
Alex, I am totally with Erik that on the language level, we can reach this
ambitious goal.
When building Jangaroo, a lot of effort went into the compiler, and it
still is not fully syntactically compatible with AS3 and doesn't do any
type checking.
Having Falcon and brilliant developers who know it so well to implement the
cross-compiler, we can now concentrate on the few remaining challenging
aspects.
I agree that E4X is probably out of reach, and so is flash_proxy stuff, so
e.g. some Flex collection stuff won't be fully supported.
Also, I am still not totally sure about IE < 9. To work around the missing
getter/setter support would be hard and quite an effort, but after all
possible, and it seems we need to support the old IE family to be
"enterprise-compatible"...
-Frank-
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Erik de Bruin <er...@ixsoftware.nl>.
"Full" AS to JS cross-compilation is well within our reach, apart from
E4X, which is entirely absent from all browsers except old Firefox
builds. If you look at the Wiki, I have made a table of most of the
language features of AS and indicated which solutions for the
disparities are possible. So far, when looking at JS + 'goog', I don't
see any actual show stoppers. There might be some 'nasty' workarounds
needed, but we can hide those from the user/developer ;-)
The real challenge is the frameworks on both ends (Flex SDK and
"FlexJS"). I'm leaning towards the 'long' solution, where we try to
support as much of the Flex SDK on the JS side as possible, again
using 'goog'. Having the AS - JS compilation in FalconJx 'nearly 100%'
language feature complete (and very extensible) makes it possible to
use whatever framework we want on either side.
EdB
On Thu, Dec 27, 2012 at 4:38 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 12/27/12 5:33 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>
>> I'm not sure how your solution provides for this? Mine doesn't either,
>> mind you, but I gave up perfection for simplicity very early in this
>> thread ;-)
>>
> +1 on simplicity vs perfection.
>
> IMO, If you take on full AS to JS cross-compilation, it is a very difficult
> task full of these edge cases. But I want to (at least at first) only
> cross-compile a subset of AS to JS. I am hopeful there is a subset that is
> straight forward to cross-compile that is sufficient enough for folks to
> build enterprise class apps. We would add warnings/errors to the compiler
> to catch the edge cases like untyped or (* typed) optional params.
>
> I think I recall that for..in iteration of classes is also an issue. Seems
> like we could live without that or require that you provide a filter
> function for the cases where you need it.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Cosma Colanicchia <co...@gmail.com>.
I'm following the discussions about JS transcoding in the last weeks - I do
not feel skilled enough to contribute, but I'd like to thanks you all (and
Frank Wienberg in particular) for the detailed explanations - really
interesting stuff.
2012/12/28 Erik de Bruin <er...@ixsoftware.nl>
> Both solutions have been implemented in FalconJx, I'm moving on.
>
> EdB
>
>
>
> On Fri, Dec 28, 2012 at 1:25 AM, Frank Wienberg <fr...@jangaroo.net>
> wrote:
> > On Thu, Dec 27, 2012 at 2:33 PM, Erik de Bruin <er...@ixsoftware.nl>
> wrote:
> >
> >> Frank,
> >>
> >> I did read your blog, I'm not that stubborn ;-)
> >>
> >
> > Good to hear, I was beginning to suspect you are ;-)
> >
> >
> >> I think you're addressing an edge case (passing 'undefined') to make
> >> your point, but that is fine as it helps focus me on getting the
> >> optimal solution. I say optimal, not perfect, for a reason, which is:
> >>
> >
> > Sorry, but I don't get your point. Even if you think I discovered an edge
> > case that might not make such a big difference in practice, what speaks *
> > against* my solution?
> >
> > - It resembles the original ActionScript semantics
> > - It is easy to understand (look for the number of actual parameters,
> > and if there are not enough of them, ...)
> > - It is easy to generate and doesn't need any more generated code than
> > your solution
> > - It is more efficient than your solution
> > - Mike already implemented it
> >
> >
> >
> >>
> >> As long as we're talking edge cases, I noticed your blog also invokes
> >> one to make it's point, namely using an untyped parameter. Your
> >> function signature is "insult(s = 'fool')". Only when the parameter
> >> you're setting a default for is untyped will it's value be
> >> 'undefined', which you are testing for in your blog. In all cases=
> >> where you declare a type for the parameter ("insult(s:String =
> >> 'fool')"), the value assigned to it when you pass 'undefined' is the
> >> initial for that type, i.e 'null' for String and Object, NaN for
> >> Number, 0 for int, false for Boolean, etc..
> >>
> >> I'm not sure how your solution provides for this? Mine doesn't either,
> >> mind you, but I gave up perfection for simplicity very early in this
> >> thread ;-)
> >>
> >
> > It does not. I consider this case another problem. That's why I used an
> > untyped parameter to demonstrate how ActionScript handles default
> parameter
> > values.
> >
> > In ActionScript, it is simply not allowed to stuff a wrong value into a
> > typed parameter or variable. And it is not allowed to leave out a
> required
> > (= non-optional) parameter.
> > However, there are some cases where implicit type conversion (coercion)
> > takes place. Your example of a parameter of type String that is passed
> > undefined is an example of coercion and has nothing to do with default
> > parameter values. It is the same as assigning undefined to a local
> variable
> > of type String: the variable is null afterwards. Only that the
> "assignment"
> > happens in the function call.
> > So far, we do not perform any type checking at run-time. Why? Because we
> > rely on the compiler refusing to compile in case of type errors. So we
> > wouldn't add any code inside the function that checks whether
> > parameter sactually contains a
> > String, because we expect the calling code to have been type-checked.
> > In the same sense, we should not add code inside the function to check
> for
> > undefined and then assign the initial value for the type (here: null),
> > because a variable of type String should never be undefined in the first
> > place. Instead, this coercion should be generated in the *calling* code!
> > Why? Because if 90% of the calling code can be statically proven to use
> the
> > correct type (ruling out the value undefined for a String), always doing
> a
> > dynamic check for undefined at run-time would be waste and inefficient.
> > Note that TypeScript, too, refrains from generating any JavaScript code
> > that does type checking; all type checking is done at compile time.
> > Coercion of a literal value like undefined to a String can simply be done
> > at compile time. However, in case of complex untyped values used as typed
> > values, we'd have to do type *coercions* at run-time. E.g. imagine we
> have
> > some veryComplicatedFunction():*, and an ActionScript expression of
> > foo(veryComplicatedFunction()), we'd have to translate it to
> > foo(coerceToString(veryComplicatedFunction())).
> > If we plan to implement type coercions like in ActionScript (at least
> > somewhere in the future), here is another argument against checking a
> > parameter for undefined to assign its default value: once we have
> > implemented coercion, the function body would not "see" undefined, but
> null,
> > and could not distinguish it from a null explicitly given by the caller.
> > And handing in null for a String parameter with a default value of
> 'foo', I
> > dare say, is no longer an edge case and thus should behave like in "real"
> > ActionScript. Using the arguments.length approach, the called function
> can
> > tell the difference and behave correctly.
> >
> > Last but not least, what about coercion if the function is called
> directly
> > from JavaScript? Well, then, we have a problem, anyway, because we also
> do
> > not type-check. We could either mimic ActionScript's ExternalInterface
> for
> > code meant to be called from JavaScript and add type checking and
> coercion
> > code there (in a wrapper function), or live with possible errors at
> > run-time for a simpler and more efficient solution.
> >
> > Sorry I had to say all that, please please nobody cite XKCD's "someone's
> > wrong on the internet" again! ;-)
> >
> > Greetings
> > -Frank-
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Both solutions have been implemented in FalconJx, I'm moving on.
EdB
On Fri, Dec 28, 2012 at 1:25 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
> On Thu, Dec 27, 2012 at 2:33 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> Frank,
>>
>> I did read your blog, I'm not that stubborn ;-)
>>
>
> Good to hear, I was beginning to suspect you are ;-)
>
>
>> I think you're addressing an edge case (passing 'undefined') to make
>> your point, but that is fine as it helps focus me on getting the
>> optimal solution. I say optimal, not perfect, for a reason, which is:
>>
>
> Sorry, but I don't get your point. Even if you think I discovered an edge
> case that might not make such a big difference in practice, what speaks *
> against* my solution?
>
> - It resembles the original ActionScript semantics
> - It is easy to understand (look for the number of actual parameters,
> and if there are not enough of them, ...)
> - It is easy to generate and doesn't need any more generated code than
> your solution
> - It is more efficient than your solution
> - Mike already implemented it
>
>
>
>>
>> As long as we're talking edge cases, I noticed your blog also invokes
>> one to make it's point, namely using an untyped parameter. Your
>> function signature is "insult(s = 'fool')". Only when the parameter
>> you're setting a default for is untyped will it's value be
>> 'undefined', which you are testing for in your blog. In all cases=
>> where you declare a type for the parameter ("insult(s:String =
>> 'fool')"), the value assigned to it when you pass 'undefined' is the
>> initial for that type, i.e 'null' for String and Object, NaN for
>> Number, 0 for int, false for Boolean, etc..
>>
>> I'm not sure how your solution provides for this? Mine doesn't either,
>> mind you, but I gave up perfection for simplicity very early in this
>> thread ;-)
>>
>
> It does not. I consider this case another problem. That's why I used an
> untyped parameter to demonstrate how ActionScript handles default parameter
> values.
>
> In ActionScript, it is simply not allowed to stuff a wrong value into a
> typed parameter or variable. And it is not allowed to leave out a required
> (= non-optional) parameter.
> However, there are some cases where implicit type conversion (coercion)
> takes place. Your example of a parameter of type String that is passed
> undefined is an example of coercion and has nothing to do with default
> parameter values. It is the same as assigning undefined to a local variable
> of type String: the variable is null afterwards. Only that the "assignment"
> happens in the function call.
> So far, we do not perform any type checking at run-time. Why? Because we
> rely on the compiler refusing to compile in case of type errors. So we
> wouldn't add any code inside the function that checks whether
> parameter sactually contains a
> String, because we expect the calling code to have been type-checked.
> In the same sense, we should not add code inside the function to check for
> undefined and then assign the initial value for the type (here: null),
> because a variable of type String should never be undefined in the first
> place. Instead, this coercion should be generated in the *calling* code!
> Why? Because if 90% of the calling code can be statically proven to use the
> correct type (ruling out the value undefined for a String), always doing a
> dynamic check for undefined at run-time would be waste and inefficient.
> Note that TypeScript, too, refrains from generating any JavaScript code
> that does type checking; all type checking is done at compile time.
> Coercion of a literal value like undefined to a String can simply be done
> at compile time. However, in case of complex untyped values used as typed
> values, we'd have to do type *coercions* at run-time. E.g. imagine we have
> some veryComplicatedFunction():*, and an ActionScript expression of
> foo(veryComplicatedFunction()), we'd have to translate it to
> foo(coerceToString(veryComplicatedFunction())).
> If we plan to implement type coercions like in ActionScript (at least
> somewhere in the future), here is another argument against checking a
> parameter for undefined to assign its default value: once we have
> implemented coercion, the function body would not "see" undefined, but null,
> and could not distinguish it from a null explicitly given by the caller.
> And handing in null for a String parameter with a default value of 'foo', I
> dare say, is no longer an edge case and thus should behave like in "real"
> ActionScript. Using the arguments.length approach, the called function can
> tell the difference and behave correctly.
>
> Last but not least, what about coercion if the function is called directly
> from JavaScript? Well, then, we have a problem, anyway, because we also do
> not type-check. We could either mimic ActionScript's ExternalInterface for
> code meant to be called from JavaScript and add type checking and coercion
> code there (in a wrapper function), or live with possible errors at
> run-time for a simpler and more efficient solution.
>
> Sorry I had to say all that, please please nobody cite XKCD's "someone's
> wrong on the internet" again! ;-)
>
> Greetings
> -Frank-
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Dec 27, 2012 at 2:33 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Frank,
>
> I did read your blog, I'm not that stubborn ;-)
>
Good to hear, I was beginning to suspect you are ;-)
> I think you're addressing an edge case (passing 'undefined') to make
> your point, but that is fine as it helps focus me on getting the
> optimal solution. I say optimal, not perfect, for a reason, which is:
>
Sorry, but I don't get your point. Even if you think I discovered an edge
case that might not make such a big difference in practice, what speaks *
against* my solution?
- It resembles the original ActionScript semantics
- It is easy to understand (look for the number of actual parameters,
and if there are not enough of them, ...)
- It is easy to generate and doesn't need any more generated code than
your solution
- It is more efficient than your solution
- Mike already implemented it
>
> As long as we're talking edge cases, I noticed your blog also invokes
> one to make it's point, namely using an untyped parameter. Your
> function signature is "insult(s = 'fool')". Only when the parameter
> you're setting a default for is untyped will it's value be
> 'undefined', which you are testing for in your blog. In all cases=
> where you declare a type for the parameter ("insult(s:String =
> 'fool')"), the value assigned to it when you pass 'undefined' is the
> initial for that type, i.e 'null' for String and Object, NaN for
> Number, 0 for int, false for Boolean, etc..
>
> I'm not sure how your solution provides for this? Mine doesn't either,
> mind you, but I gave up perfection for simplicity very early in this
> thread ;-)
>
It does not. I consider this case another problem. That's why I used an
untyped parameter to demonstrate how ActionScript handles default parameter
values.
In ActionScript, it is simply not allowed to stuff a wrong value into a
typed parameter or variable. And it is not allowed to leave out a required
(= non-optional) parameter.
However, there are some cases where implicit type conversion (coercion)
takes place. Your example of a parameter of type String that is passed
undefined is an example of coercion and has nothing to do with default
parameter values. It is the same as assigning undefined to a local variable
of type String: the variable is null afterwards. Only that the "assignment"
happens in the function call.
So far, we do not perform any type checking at run-time. Why? Because we
rely on the compiler refusing to compile in case of type errors. So we
wouldn't add any code inside the function that checks whether
parameter sactually contains a
String, because we expect the calling code to have been type-checked.
In the same sense, we should not add code inside the function to check for
undefined and then assign the initial value for the type (here: null),
because a variable of type String should never be undefined in the first
place. Instead, this coercion should be generated in the *calling* code!
Why? Because if 90% of the calling code can be statically proven to use the
correct type (ruling out the value undefined for a String), always doing a
dynamic check for undefined at run-time would be waste and inefficient.
Note that TypeScript, too, refrains from generating any JavaScript code
that does type checking; all type checking is done at compile time.
Coercion of a literal value like undefined to a String can simply be done
at compile time. However, in case of complex untyped values used as typed
values, we'd have to do type *coercions* at run-time. E.g. imagine we have
some veryComplicatedFunction():*, and an ActionScript expression of
foo(veryComplicatedFunction()), we'd have to translate it to
foo(coerceToString(veryComplicatedFunction())).
If we plan to implement type coercions like in ActionScript (at least
somewhere in the future), here is another argument against checking a
parameter for undefined to assign its default value: once we have
implemented coercion, the function body would not "see" undefined, but null,
and could not distinguish it from a null explicitly given by the caller.
And handing in null for a String parameter with a default value of 'foo', I
dare say, is no longer an edge case and thus should behave like in "real"
ActionScript. Using the arguments.length approach, the called function can
tell the difference and behave correctly.
Last but not least, what about coercion if the function is called directly
from JavaScript? Well, then, we have a problem, anyway, because we also do
not type-check. We could either mimic ActionScript's ExternalInterface for
code meant to be called from JavaScript and add type checking and coercion
code there (in a wrapper function), or live with possible errors at
run-time for a simpler and more efficient solution.
Sorry I had to say all that, please please nobody cite XKCD's "someone's
wrong on the internet" again! ;-)
Greetings
-Frank-
Re: [FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Posted by Alex Harui <ah...@adobe.com>.
On 12/27/12 5:33 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> I'm not sure how your solution provides for this? Mine doesn't either,
> mind you, but I gave up perfection for simplicity very early in this
> thread ;-)
>
+1 on simplicity vs perfection.
IMO, If you take on full AS to JS cross-compilation, it is a very difficult
task full of these edge cases. But I want to (at least at first) only
cross-compile a subset of AS to JS. I am hopeful there is a subset that is
straight forward to cross-compile that is sufficient enough for folks to
build enterprise class apps. We would add warnings/errors to the compiler
to catch the edge cases like untyped or (* typed) optional params.
I think I recall that for..in iteration of classes is also an issue. Seems
like we could live without that or require that you provide a filter
function for the cases where you need it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Frank,
I did read your blog, I'm not that stubborn ;-)
I think you're addressing an edge case (passing 'undefined') to make
your point, but that is fine as it helps focus me on getting the
optimal solution. I say optimal, not perfect, for a reason, which is:
As long as we're talking edge cases, I noticed your blog also invokes
one to make it's point, namely using an untyped parameter. Your
function signature is "insult(s = 'fool')". Only when the parameter
you're setting a default for is untyped will it's value be
'undefined', which you are testing for in your blog. In all cases=
where you declare a type for the parameter ("insult(s:String =
'fool')"), the value assigned to it when you pass 'undefined' is the
initial for that type, i.e 'null' for String and Object, NaN for
Number, 0 for int, false for Boolean, etc..
I'm not sure how your solution provides for this? Mine doesn't either,
mind you, but I gave up perfection for simplicity very early in this
thread ;-)
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Frank Wienberg <fr...@jangaroo.net>.
Of course it can! Namely when you hand in an undefined value for a
parameter. In the blog post, there is an example where your solution would
behave differently when compiled/run with "real" ActionScript / FlashPlayer.
In AS, if a function foo has an optional parameter, it is something
different whether you call foo() or foo(undefined). Fortunately, this
difference can also be detected in JavaScript, by inspecting
arguments.length, as described above. If you don't believe me, try run the
example from the blog post through mxmlc and run it with FlashPlayer, and
you'll see that ActionScript behaves like I said. I also only found out by
trying -- because there is no ActionScript language spec :-(
-Frank-
On Thu, Dec 27, 2012 at 11:31 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Frank,
>
> In what way can the the type of an argument be 'undefined' other than
> if that argument is NOT PASSED?
>
> <code>
> function func(optArg) {
> optArg = typeof optArg !== 'undefined' ? optArg : "yes";
>
> return "Use default: " + optArg;
> }
> func("no"); // Use default: no
> func(); // Use default: yes
> </code>
>
> EdB
>
> On Thu, Dec 27, 2012 at 11:07 AM, Frank Wienberg <fr...@jangaroo.net>
> wrote:
> > On Sun, Dec 23, 2012 at 11:32 AM, Erik de Bruin <er...@ixsoftware.nl>
> wrote:
> >
> >> My personal preference for optional arguments goes to:
> >>
> >> optArg = optArg !== 'undefined' ? optArg : defaultValue;
> >>
> >
> > Hi Erik,
> >
> > the way we implement this should not change ActionScript language
> > semantics. Sorry, but this is not a question of personal preference.
> > As explained in detail in this blog
> > post<
> http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html>,
> > ActionScript does *not* replace undefined parameters by their default
> > values, but it only uses the default values when less actual parameters
> are
> > given in the call. Thus, the generated code has to check
> arguments.length.
> > The blog post discusses some optimizations (performance, code size), but
> if
> > you want a solution that is easy to generate (one default parameter =>
> one
> > line of generated code) *and* leads to the correct semantics, please use
> >
> > if (arguments.length < optArgIndex) optArg = defaultValue;
> >
> > I'm a big fan of ?: expressions, but in this case, an if-statement is
> > clearly the better choice, as "else", the parameter value should stay
> as-is
> > (and not be assigned to itself).
> > Optimization: When there are multiple optional arguments, it is obvious
> > that the corresponding if-statements should be sorted by decreasing
> > argument index and then nested, because it is obsolete to check for
> > arguments.length
> > < 4 if you already know that arguments.length < 3. But I agree that we
> can
> > add this optimization later. I just would like to see us get the
> > *semantics*right in the first go.
> >
> > Greetings
> > -Frank-
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Frank,
In what way can the the type of an argument be 'undefined' other than
if that argument is NOT PASSED?
<code>
function func(optArg) {
optArg = typeof optArg !== 'undefined' ? optArg : "yes";
return "Use default: " + optArg;
}
func("no"); // Use default: no
func(); // Use default: yes
</code>
EdB
On Thu, Dec 27, 2012 at 11:07 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
> On Sun, Dec 23, 2012 at 11:32 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> My personal preference for optional arguments goes to:
>>
>> optArg = optArg !== 'undefined' ? optArg : defaultValue;
>>
>
> Hi Erik,
>
> the way we implement this should not change ActionScript language
> semantics. Sorry, but this is not a question of personal preference.
> As explained in detail in this blog
> post<http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html>,
> ActionScript does *not* replace undefined parameters by their default
> values, but it only uses the default values when less actual parameters are
> given in the call. Thus, the generated code has to check arguments.length.
> The blog post discusses some optimizations (performance, code size), but if
> you want a solution that is easy to generate (one default parameter => one
> line of generated code) *and* leads to the correct semantics, please use
>
> if (arguments.length < optArgIndex) optArg = defaultValue;
>
> I'm a big fan of ?: expressions, but in this case, an if-statement is
> clearly the better choice, as "else", the parameter value should stay as-is
> (and not be assigned to itself).
> Optimization: When there are multiple optional arguments, it is obvious
> that the corresponding if-statements should be sorted by decreasing
> argument index and then nested, because it is obsolete to check for
> arguments.length
> < 4 if you already know that arguments.length < 3. But I agree that we can
> add this optimization later. I just would like to see us get the
> *semantics*right in the first go.
>
> Greetings
> -Frank-
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Sun, Dec 23, 2012 at 11:32 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> My personal preference for optional arguments goes to:
>
> optArg = optArg !== 'undefined' ? optArg : defaultValue;
>
Hi Erik,
the way we implement this should not change ActionScript language
semantics. Sorry, but this is not a question of personal preference.
As explained in detail in this blog
post<http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html>,
ActionScript does *not* replace undefined parameters by their default
values, but it only uses the default values when less actual parameters are
given in the call. Thus, the generated code has to check arguments.length.
The blog post discusses some optimizations (performance, code size), but if
you want a solution that is easy to generate (one default parameter => one
line of generated code) *and* leads to the correct semantics, please use
if (arguments.length < optArgIndex) optArg = defaultValue;
I'm a big fan of ?: expressions, but in this case, an if-statement is
clearly the better choice, as "else", the parameter value should stay as-is
(and not be assigned to itself).
Optimization: When there are multiple optional arguments, it is obvious
that the corresponding if-statements should be sorted by decreasing
argument index and then nested, because it is obsolete to check for
arguments.length
< 4 if you already know that arguments.length < 3. But I agree that we can
add this optimization later. I just would like to see us get the
*semantics*right in the first go.
Greetings
-Frank-
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Hi,
My personal preference for optional arguments goes to:
optArg = optArg !== 'undefined' ? optArg : defaultValue;
Which would be a line entered at the top of the function block for
each of the optional arguments, which with my current understanding of
the compiler innards seems like something that I should be able to
implement. One node -> one line.
I like your solution for the ... parameter:
rest = Array.prototype.slice.call(arguments, numberOfOtherArguments);
As a 'one liner', it neatly fits with my vey limited understanding of
the compiler innards ;-)
Thank you!
EdB
On Sat, Dec 22, 2012 at 10:42 PM, Frank Wienberg <fr...@jangaroo.net> wrote:
> On Sat, Dec 22, 2012 at 6:46 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> default value (if present). I figured out how to handle
>> that in JS
>>
>
> Hi Erik,
>
> just so that you do not run into a minor fallacy Bernd Paradies went into
> in FalconJS: did you have a look at my blog post tackling exactly that
> feature, default parameter values:
> http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
> And while you're at it, what about implementing the "..." rest parameter
> next?
> http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
> You see, it's my obsession, too... ;-)
>
> Best,
> -Frank-
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Sat, Dec 22, 2012 at 6:46 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> default value (if present). I figured out how to handle
> that in JS
>
Hi Erik,
just so that you do not run into a minor fallacy Bernd Paradies went into
in FalconJS: did you have a look at my blog post tackling exactly that
feature, default parameter values:
http://blog.jangaroo.net/2012/01/simulating-actionscript-parameter.html
And while you're at it, what about implementing the "..." rest parameter
next?
http://blog.jangaroo.net/2012/01/simulating-actionscript-rest-parameter.html
You see, it's my obsession, too... ;-)
Best,
-Frank-
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Mike,
I ended up in 'org.apache.flex.compiler.internal.js.codgen.ASBlockWalker',
the 'visitParameter' method, where I commented out all code but the
first two lines. That seemed to do the trick :-) Do you want me to
check in my commented "solution"? For kicks and just to get the
process running?
I noticed that that method not only emits the argument name and type,
but also a default value (if present). I figured out how to handle
that in JS, so I accept that as my next mission... after the holidays.
Now: go have fun with the family, don't let my obsession distract you
anymore :-)
EdB
On Sat, Dec 22, 2012 at 12:38 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Erik,
>
> I've got a challenge for you. Try to figure out how to change how a
> parementer is emited and fix the;
>
> - com.example.components.MyTextButton = function(value:String) {
>
> line to;
>
> - com.example.components.MyTextButton = function(value) {
>
> If you can figure that out, it's all down hill.
>
>
> Mike
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> Awesome, Mike!
>>
>> Now you've gone and created a reason for me to waste a considerable
>> amount of the holidays on getting to know this code and "finish" the
>> conversion table ;-)
>>
>> Have a very merry Xmas,
>>
>> EdB
>>
>>
>>
>> On Sat, Dec 22, 2012 at 1:00 AM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>>>
>>>
>>> Hi,
>>>
>>> Well I busted my A$$ before I hit vacation, Erik you can look at
>>> TestGoogEmiter and the JSGoogEmitter to see the black majik I whipped up
>>> today.
>>>
>>> Basically with the NEW FalconJx (BTW I'm starting to like this name now,
>>> the
>>> "x" with Fle"X"), cross compiler is doing this all. I know there are
>>> missing
>>> "this, super" etc etc etc, but this things is working!
>>>
>>> And all that little stuff is easy to add now. Like I said in my commits,
>>> I
>>> have package down to expressions working and it creates valid AS3 source
>>> code from the AST.
>>>
>>> Now it's just work filling in all the holes you have listed in the as->js
>>> conversion table.
>>>
>>> Frank, I'm sure you could look at my code and take the JSGoogEmitter as
>>> an
>>> example and create a prototype JSRequireEmitter with the pattern I have
>>> setup.
>>>
>>> I'm still refactoring but it's looking good.
>>>
>>> Peace and happy new year,
>>> Mike
>>>
>>>
>>>
>>> ----------------------------------------------------------------------------
>>> AS Code
>>>
>>> package com.example.components
>>> {
>>>
>>> import org.apache.flex.html.staticControls.TextButton;
>>>
>>> public class MyTextButton extends TextButton
>>> {
>>> public function MyTextButton()
>>> {
>>> if (foo() != 42) {
>>> bar();
>>> }
>>> }
>>>
>>> private var _privateVar:String = "do ";
>>>
>>> public var publicProperty:Number = 100;
>>>
>>> public function myFunction(value: String): String
>>> {
>>> return "Don't " + _privateVar + value;
>>> }
>>> }
>>> }
>>>
>>>
>>>
>>>
>>> ----------------------------------------------------------------------------
>>> JS Code
>>>
>>>
>>>
>>> goog.provide('com.example.components.MyTextButton');
>>>
>>> goog.require('org.apache.flex.html.staticControls.TextButton');
>>>
>>> /**
>>> * @constructor
>>> */
>>> com.example.components.MyTextButton = function() {
>>> if (foo() != 42) {
>>> bar();
>>> }
>>> }
>>>
>>> /**
>>> * @type {String}
>>> */
>>> com.example.components.MyTextButton.prototype._privateVar = "do ";
>>>
>>> /**
>>> * @type {Number}
>>> */
>>> com.example.components.MyTextButton.prototype.publicProperty = 100;
>>>
>>> /**
>>> * @this {com.example.components.MyTextButton}
>>> * @param {String} value
>>> * @return {String}
>>> */
>>> com.example.components.MyTextButton = function(value:String) {
>>> return "Don't " + _privateVar + value;
>>> }
>>>
>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Posted by Daniel Wasilewski <de...@gmail.com>.
And one more thing,
We use to think of ourselves, programmers, a problem solvers.
We love that phrase so much, that we even creating more for ourself by
making wrong design decisions.
I realised that all my talks seems to many of you as to much care on the
initial state of the process.
Like working against anti pattern called early optimisation. I don't
think about optimisations here, but right approach and only.
In general I stick to one rule that has been invented when computer
science was unborn baby.
/"Don't solve the problems, try to avoid them"//
//A Einstein/
Re: [FalconJx] Package down to Expression production; JSGoogEmiter
prototype
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Erik,
I've got a challenge for you. Try to figure out how to change how a
parementer is emited and fix the;
- com.example.components.MyTextButton = function(value:String) {
line to;
- com.example.components.MyTextButton = function(value) {
If you can figure that out, it's all down hill.
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Awesome, Mike!
>
> Now you've gone and created a reason for me to waste a considerable
> amount of the holidays on getting to know this code and "finish" the
> conversion table ;-)
>
> Have a very merry Xmas,
>
> EdB
>
>
>
> On Sat, Dec 22, 2012 at 1:00 AM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>>
>> Hi,
>>
>> Well I busted my A$$ before I hit vacation, Erik you can look at
>> TestGoogEmiter and the JSGoogEmitter to see the black majik I whipped up
>> today.
>>
>> Basically with the NEW FalconJx (BTW I'm starting to like this name now, the
>> "x" with Fle"X"), cross compiler is doing this all. I know there are missing
>> "this, super" etc etc etc, but this things is working!
>>
>> And all that little stuff is easy to add now. Like I said in my commits, I
>> have package down to expressions working and it creates valid AS3 source
>> code from the AST.
>>
>> Now it's just work filling in all the holes you have listed in the as->js
>> conversion table.
>>
>> Frank, I'm sure you could look at my code and take the JSGoogEmitter as an
>> example and create a prototype JSRequireEmitter with the pattern I have
>> setup.
>>
>> I'm still refactoring but it's looking good.
>>
>> Peace and happy new year,
>> Mike
>>
>>
>> ----------------------------------------------------------------------------
>> AS Code
>>
>> package com.example.components
>> {
>>
>> import org.apache.flex.html.staticControls.TextButton;
>>
>> public class MyTextButton extends TextButton
>> {
>> public function MyTextButton()
>> {
>> if (foo() != 42) {
>> bar();
>> }
>> }
>>
>> private var _privateVar:String = "do ";
>>
>> public var publicProperty:Number = 100;
>>
>> public function myFunction(value: String): String
>> {
>> return "Don't " + _privateVar + value;
>> }
>> }
>> }
>>
>>
>>
>> ----------------------------------------------------------------------------
>> JS Code
>>
>>
>>
>> goog.provide('com.example.components.MyTextButton');
>>
>> goog.require('org.apache.flex.html.staticControls.TextButton');
>>
>> /**
>> * @constructor
>> */
>> com.example.components.MyTextButton = function() {
>> if (foo() != 42) {
>> bar();
>> }
>> }
>>
>> /**
>> * @type {String}
>> */
>> com.example.components.MyTextButton.prototype._privateVar = "do ";
>>
>> /**
>> * @type {Number}
>> */
>> com.example.components.MyTextButton.prototype.publicProperty = 100;
>>
>> /**
>> * @this {com.example.components.MyTextButton}
>> * @param {String} value
>> * @return {String}
>> */
>> com.example.components.MyTextButton = function(value:String) {
>> return "Don't " + _privateVar + value;
>> }
>>
>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Awesome, Mike!
Now you've gone and created a reason for me to waste a considerable
amount of the holidays on getting to know this code and "finish" the
conversion table ;-)
Have a very merry Xmas,
EdB
On Sat, Dec 22, 2012 at 1:00 AM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
>
> Hi,
>
> Well I busted my A$$ before I hit vacation, Erik you can look at
> TestGoogEmiter and the JSGoogEmitter to see the black majik I whipped up
> today.
>
> Basically with the NEW FalconJx (BTW I'm starting to like this name now, the
> "x" with Fle"X"), cross compiler is doing this all. I know there are missing
> "this, super" etc etc etc, but this things is working!
>
> And all that little stuff is easy to add now. Like I said in my commits, I
> have package down to expressions working and it creates valid AS3 source
> code from the AST.
>
> Now it's just work filling in all the holes you have listed in the as->js
> conversion table.
>
> Frank, I'm sure you could look at my code and take the JSGoogEmitter as an
> example and create a prototype JSRequireEmitter with the pattern I have
> setup.
>
> I'm still refactoring but it's looking good.
>
> Peace and happy new year,
> Mike
>
>
> ----------------------------------------------------------------------------
> AS Code
>
> package com.example.components
> {
>
> import org.apache.flex.html.staticControls.TextButton;
>
> public class MyTextButton extends TextButton
> {
> public function MyTextButton()
> {
> if (foo() != 42) {
> bar();
> }
> }
>
> private var _privateVar:String = "do ";
>
> public var publicProperty:Number = 100;
>
> public function myFunction(value: String): String
> {
> return "Don't " + _privateVar + value;
> }
> }
> }
>
>
>
> ----------------------------------------------------------------------------
> JS Code
>
>
>
> goog.provide('com.example.components.MyTextButton');
>
> goog.require('org.apache.flex.html.staticControls.TextButton');
>
> /**
> * @constructor
> */
> com.example.components.MyTextButton = function() {
> if (foo() != 42) {
> bar();
> }
> }
>
> /**
> * @type {String}
> */
> com.example.components.MyTextButton.prototype._privateVar = "do ";
>
> /**
> * @type {Number}
> */
> com.example.components.MyTextButton.prototype.publicProperty = 100;
>
> /**
> * @this {com.example.components.MyTextButton}
> * @param {String} value
> * @return {String}
> */
> com.example.components.MyTextButton = function(value:String) {
> return "Don't " + _privateVar + value;
> }
>
>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl