I can completly agree with Ray. I don’t see any reason why to treat array as an object “sometimes”. If language defines native type Array it should be always array.

If I remember correctly, this is due to array accessing on an object.

It’s like an array ‘really’ isn’t an array like you would think becasue of the way AS language works.

I am no engineer but I really remember this being brought up by Gordon Smith of Adobe.

There is some reason for this, I just can’t think of it.

This comment isn’t about the performance of the different number types, but about the way they behave.

As I reported a while back, there seems to be no concept of integer math, which is very strange for someone coming from a C/Java background:

var xx :int = 3;
var yy :int = 2;
someArray[xx/yy] = “MyStringValue”;

Rather than storing the value at array element 1, the Array is now broken and has a value stored under the property name “1.5″.

Another thing I discovered recently is that you can’t depend on the type of a number, because it can change out from under you:

var nn :Number = 1.2;
trace(“nn is ” + getQualifiedClassName(nn)); // outputs “nn is Number”
nn += 1.8;
trace(“nn is ” + getQualifiedClassName(nn)); // outputs “nn is int”

This is very disturbing, because I would like to write code that serializes objects to send to a server, and metadata is not sent. The format of the binary data is well-known for each service request to the server, but on the client I would like the actual serialization code to be dumb and just examine the objects passed to it and send them along. However, I cannot depend on a Number looking like a Number so that I know to use my IDataOutput’s writeDouble method instead of the writeInt method.

It would be great if this were fixed in the next release, but I’m not holding my breath.