incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Wienberg <fr...@jangaroo.net>
Subject Re: [FalconJx] Package down to Expression production; JSGoogEmiter prototype
Date Thu, 27 Dec 2012 12:19:39 GMT
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 <erik@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 <frank@jangaroo.net>
> wrote:
> > On Sun, Dec 23, 2012 at 11:32 AM, Erik de Bruin <erik@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
>

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