I wanted to do:

public function SomeClass(minVal:Number,maxVal:Number,defaultVal:Number=null) {
if (defaultVal==null) {defaultVal=minVal;}

The workaround is to default the parameter to “Infinity” and check against that since Infinity could never be a valid value for my class:

public function SomeClass(minVal:Number,maxVal:Number,defaultVal:Number=Infinity) {
if (!isFinite(defaultVal)) {defaultVal=minVal;}

new int(4) // => 4

5.5.toString() // => “5.5″

These statements should be quite conclusive, instances of Number are instances of Object. That doesn’t mean that variables typed as Number, int, uint and Boolean work like variables typed as Object, for example you can’t null them.

But there’s a difference here, “myNumber is Object” tests the value of the “myNumber” variable, whereas “myNumber = null” sets the variable to null. So Number objects are objects, but variables typed Number are not like other variables, but subject to compiler and runtime optimizations.

—

Another weird detail, if you want to call a method on a number literal you can’t do

5.toString()

because the “.” is considered to be the decimal point, however

5..toString()

works fine (because “5.” is the same as “5.0″).

http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/

“You might be alarmed to hear then, that isNaN() applied on a Number typed variable, which have previously been assigned null, will return false.”

1. var foo : Number = null; //So this is really 0, established prior.
2. trace(”foo=”+foo); //prints 0
3. isNaN(foo) == false, is correct. // foo is 0, which is a Number.
The result of isNaN seems reasonable to me.

However i do see your point about the Number class itself and not being able to test for null. However as you can see above – the Number is never null
but rather 0.
I think that probably the compiler should generate an error when you assign null to a type Number rather than just a warning, which would then make it consistent with the conditional testing against null.

Nice post.

http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000048.html

var a:Object = {};
var b:Object = {}

a == b //false

var c:Number = 1;
var d:Number = 1;

c == d //true

Additionally, it’s important to know that null, undefined, and 0 may all go through type conversions when you do comparisons or assignment.

//EXAMPLE 1
var nullNum:Number = null;
trace(nullNum) //0

It is 0 because null gets type converted to work as a Number. That’s why isNaN() fails.

//EXAMPLE 2
var zero:Number = 0;
if(!zero)
{
trace(”zero got type converted”);
}

This can be tricky when you actually want a nullable value. For instance, the following code works:

var styles:Object = {color: 0xff0000, alpha: 0.5};
if(styles.color)
{
//if color is defined, do something
}

…but what happens when you change the value of “color” to black?

var styles:Object = {color: 0×000000, alpha: 0.5};
if(styles.color)
{
//the code in this if statement won’t run
}

Color is now equal to zero, which is type converted and becomes false in the comparison.

In short, you’ve discovered a very tricky part of the core types. It is defined as part of the ECMAScript specification, so this stuff is documented somewhere. I’m not sure if Adobe points it out anywhere, though.