In contrast to JavaScript, ActionScript allows to specify a default value for a function (or method) parameter, like so:
1 public function insult(s = "fool") {
2 return "you " + s;
3 }
The idea is that when the method is called without providing a value for parameter s, the default value "fool" will be used. Details on what additional rules hold for declaring parameter default values are given in the Adobe documentation on function parameters and a bit less reference-like e.g. in a tutorial on Ntt.CC.
Why, it's easy, isn't it?
A straight-forward implementation in JavaScript (similar to the solution suggested by Bernd Paradies for FalconJS) would be to replace undefined paramter values by their default value:
1 function insult(s) {
if (s === undefined) {
s = "fool";
}
2 return "you " + s;
3 }
(We could now start a discussion on whether it shouldn't be
if (typeof s === "undefined") {
because in JavaScript, undefined may be redefined, but anybody who does so is, excuse me, a fool.)
In JavaScript, when you omit a parameter when calling a function, the parameter value indeed is undefined. But it is a fallacy to assume that every undefined parameter must be replaced by its default value! Consider the following ActionScript class:1 public class DefaultParameterTest {
2
3 public function DefaultParameterTest() {
4 trace("1. " + insult ("nerd"));
5 trace("2. " + insult ());
6 trace("3. " + insult (undefined));
7 }
8
9 public function insult(s = "fool") {
10 return "you " + s;
11 }
12 }
What do you think will be traced? Try it out, and you'll see that explicitly handing in undefined does not trigger the default value! Thus, the result is
1. you nerd
2. you fool
3. you undefined
(Careful, never call a JavaScript programmer "you undefined"!)
Using the straight-forward JavaScript implementation, the result would be
1. you nerd
2. you fool
3. you fool
As you can see, using parameter default values depends on the number of formal arguments, not on their value. This is the reason why they are also called optional parameters, and why after a parameter with a default value, all following parameters must also specify a default value.
Getting it right
Thus, the correct JavaScript equivalent (as generated by the Jangaroo compiler jooc) is to check the number of formal parameters. Fortunately, this can be realized by checking arguments.length:
1 function insult(s) {
if (arguments.length < 1) {
s = "fool";
}
2 return "you " + s;
3 }
In fact, this solution even provides better runtime performance when using multiple optional parameters, since multiple arguments.length checks can be nested, while the undefined checks in the straight-forward solution would be sequential. Consider the following example:
if (arguments.length < 1) {
s = "fool";
}
2 return "you " + s;
3 }
1 public function foo(p1, p2, p3 = 3, p4 = 4) {
2 return p1 + p2 + p3 + p4;
3 }
The JavaScript fragment generated by Jangaroo looks like so:
2 return p1 + p2 + p3 + p4;
3 }
1 function foo(p1, p2, p3, p4) {
if (arguments.length < 4) {
if (arguments.length < 3) {
p3 = 3;
}
p4 = 4;
}
2 return p1 + p2 + p3 + p4;
3 }
if (arguments.length < 4) {
if (arguments.length < 3) {
p3 = 3;
}
p4 = 4;
}
2 return p1 + p2 + p3 + p4;
3 }
Jangaroo even optimizes undefined default values, since left out actual parameters are undefined in JavaScript, anyway.
Alternative Solutions
We also thought of using a switch statement, generating code like the following:
1 function foo(p1, p2, p3, p4) {
switch (arguments.length) {
case 0:
case 1:
case 2:
p3 = 3;
// fall through
case 3:
p4 = 4;
}
2 return p1 + p2 + p3 + p4;
3 }
switch (arguments.length) {
case 0:
case 1:
case 2:
p3 = 3;
// fall through
case 3:
p4 = 4;
}
2 return p1 + p2 + p3 + p4;
3 }
At first sight, this solution seems more efficient, because arguments.length is only evaluated once. The reason why we still chose the nested if code layout is that the switch solution becomes either long or non-robust when using many non-optional parameters. Note the lines case 0: and case 1: in the example above: although the method should never be called with less than two parameters (since the first two are not optional), we want to handle that case, too, since Jangaroo code may be called from JavaScript, where no function signature check is performed. When the function is called with fewer parameters than required, you would still expect the default values to pop in. So the case statements would pile up when there are many non-optional parameters. However, I could imagine a mixed solution like the following:
1 function foo(p1, p2, p3, p4) {
switch (Math.max(arguments.length, 2)) {
case 2:
p3 = 3;
// fall through
case 3:
p4 = 4;
}
2 return p1 + p2 + p3 + p4;
3 }
The most intelligent solution would be to dynamically decide whether the prior length check pays off against adding several case statements. I guess I'll add that to the Jangaroo backlog!
switch (Math.max(arguments.length, 2)) {
case 2:
p3 = 3;
// fall through
case 3:
p4 = 4;
}
2 return p1 + p2 + p3 + p4;
3 }