Adobe给出的描述说实话既不准确也不正确,但它更简单,涵盖了大多数情况。
您应该尝试以下方法:
for (var key:* in dic) trace(getQualifiedClassName(key));//will give you 'String'
这种行为对于Array
并且也是如此Object
。
根据经验:int
staysint
和任何其他键都转换为其字符串表示形式(包括布尔值和浮点值,以及null
and undefined
)。
该类Dictionary
的不同之处在于它不会将非原始对象转换为String
,而是直接将它们用作键。Object
如果您愿意,他们处理所有其他值的方式是“继承的” 。
基本上,一个Object
由 2 个散列组成,一个用于字符串,一个用于整数键。并且Dictionary
添加了另一个哈希,可能只是使用对象内存地址作为整数键。
编辑:不是对实际问题的真正答案,而是我想详细解释的一点,以回应 Triynko 的评论:
哈基?你的意思是,让它以非设计的方式工作?嗯......因为它不是为处理 64 位整数而设计的,所以它当然是一个 hack。但是 64 位就是 64 位,无论它们被解释为整数还是浮点。
使用 64 位浮点数来表示 64 位整数已经是一个坏主意,因为从语义上讲,它是完全错误的(您通常可以预料到这种滥用会引起问题)。
但是然后使用他们的字符串表示作为键(如果你使用浮点数作为键,这会隐含地发生)是简单的自杀:
var f1:Number = 1000000000000003000000000.0;
var f2:Number = 1000000000000002000000000.0;
trace(f1 == f2);//false
trace(String(f1) == String(f2));//true ... kabooooom
您将很难确定 2 个 64 位整数何时会发生冲突,因为先决条件是它们的值的字符串表示形式被解释为浮点数必须相等。此外,不同的播放器版本可能具有不同的浮点字符串转换,如LightSpark等替代运行时。我真的不想依赖这个。当有足够的数据导致碰撞时,这会产生似乎无处不在的错误。而且您不会喜欢追踪它们。
此外,浮点键的性能更差,因为它们必须在用于哈希查找之前转换为字符串。如果您真的非常关心大小,那么您必须将数据作为 64 位 int 传输,然后仅在闪存端将其转换为十六进制字符串。
尽管如此,我要指出的是,许多人都非常乐意使用 XML 或 JSON,它们的开销要低得多。
带宽和任何其他硬件资源都很便宜。开发成本高。您应该编写可维护和健壮的应用程序,否则从长远来看它们会花费您更多。
问候
back2dos