数组作为单独的类型
某些脚本语言（例如 Python 和 Javascript）将数组（也称为列表）作为与哈希表（又称为字典、映射、对象）不同的数据类型。在其他脚本语言中，例如 PHP 和 Lua，数组只是一个哈希表，其键恰好是整数。 （可以针对这种特殊情况优化实现，就像当前版本的 Lua 中所做的那样，但这对语言语义是透明的。）
哪种方法更好？
从拥有一件事而不是两件事的意义上来说，统一方法更加优雅，尽管增益并不像乍一看那么大，因为您仍然需要迭代数字的概念统一
统一方法可以说更加灵活。您可以从嵌套数组开始，发现需要用其他内容对它们进行注释，然后只需添加注释，而无需重新设计数据结构以将数组与哈希表交错。
就效率而言，这似乎是一次洗礼（假设实现针对特殊情况进行了优化，就像 Lua 所做的那样）。
我缺少什么？单独的方法有什么优点吗？
Some scripting languages, such as Python and Javascript, have arrays (aka lists) as a separate datatype from hash tables (aka dictionaries, maps, objects). In other scripting languages, such as PHP and Lua, an array is merely a hash table whose keys happen to be integers. (The implementation may be optimized for that special case, as is done in the current version of Lua, but that's transparent to the language semantics.)
Which is the better approach?
The unified approach is more elegant in the sense of having one thing rather than two, though the gain isn't quite as large as it might seem at first glance, since you still need to have the notion of iterating over the numeric keys specifically.
The unified approach is arguably more flexible. You can start off with nested arrays, find you need to annotate them with other stuff, and just add the annotations, without having to rework the data structures to interleave the arrays with hash tables.
In terms of efficiency, it seems to be pretty much a wash (provided the implementation optimizes for the special case, as Lua does).
What am I missing? Does the separate approach have any advantages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
拥有单独的类型意味着您可以保证性能，并且您知道对于数组切片之类的事情将具有“正常”语义。如果您有一个统一的系统，您需要弄清楚所有操作（例如切片）对稀疏数组的含义。
Having separate types means that you can make guarantees about performance, and you know that you will have "normal" semantics for things like array slicing. If you have a unified system, you need to work out what all operations, such as slicing, mean on sparse arrays.
数组不仅仅是一张故意限制为连续整数键的表。它是一个序列，是具有明确定义顺序的 n 个项目（不是键值对，只是值）的集合。在我看来，这是一种没有空间容纳非整数键形式的附加数据的数据结构。它在概念上更简单。
此外，单独实现这两个可能会更简单，尤其是考虑添加优化时（这显然很晦涩，以至于像 Lua 这样的面向性能的语言多年来都没有实现它）使数组表现良好。
此外，灵活性点也存在争议。如果需要更复杂的注释，您很可能很快也需要多态性，在这种情况下，您应该切换到具有数组和其他属性的对象。
An array is more than a table intentionally restricted to consecutive integer keys. It's a sequence, a collection of n items (not key-value pairs, just the values) with a well-defined order. This is, in my opinion, a data structure that has no place for additional data in the form of non-integer keys. It's conceptually simpler.
Also, implementing the two seperately may be simpler, especially when considering the addition of an optimization (which is apparently obscure enough that a performance-oriented language like Lua didn't implement it for many many years) which makes arrays perform well.
Also, the flexibility point is arguable. If the need for more complex annotation arises, it's quite possible that you'll soon also need polymorphism, in which case you should just switch to objects with an array among other attributes.
如前所述，拥有两种不同的类型涉及速度和复杂性问题。然而，我发现拥有两种类型很重要的一件事是它表达了数据存储的意图。
需要注意的是，键是地图数据的一部分，而不是列表......从概念上讲。当您选择一种数据类型而不是另一种数据类型时，您就指定了您的意图。
顺便说一句，每种共享列表和地图数据类型的语言都有一定的......随之而来的烦恼。为了实现这种结合，总是需要做出某些让步，有时它们会咬你一口。这通常不是什么大问题，但可能会很烦人。
As mentioned, there are speed and complexity issues involved in having two separate types. However, one of the things that I find important about having two types is that it expresses the intent of the datastore.
The point to note that the keys are part of the data for a map, they're not for a list... conceptually. When you choose one data type over the other, you're specifying your intent.
I'll add as an aside that every language that shares a data type for lists and maps has certain... annoyances that come along with it. There are always certain concessions that need to be made to allow the combination, and they can bite you sometimes. It's generally not a big deal, but it can be annoying.