Arrays as a separate type

Some scripting languages, such as Python and Javascript, have arrays (aka lists) as a separate data type from hash tables (like dictionaries, maps, objects). In other scripting languages, such as PHP and Lua, an array is simply a hash table whose keys are integers. (The implementation can be optimized for this special case, as is done in the current version of Lua, but transparent to the semantics of the language.)

What is the best approach?

  • A single approach is more elegant in the sense of having one thing, not two, although the gain is not as great as it might seem at first glance, since you still need to have an idea about iterating over the number keys.

  • A single approach, perhaps more flexible. You can start with nested arrays, find that you need to comment on them with other material, and simply add annotations without processing the data structures to alternate the arrays using hash tables.

  • In terms of efficiency, it seems to be almost washable (assuming the implementation is optimized for the special case, as Lua does).

What am I missing? Does a separate approach have any advantages?

+8
arrays scripting data-structures language-design
source share
3 answers

An array is more than a table deliberately limited to consecutive integer keys. This is a sequence, a set of n elements (not key-value pairs, only values) with a clearly defined order. This, in my opinion, is a data structure that does not have a place for additional data in the form of non-integer keys. This is conceptually simpler.

In addition, implementing the two separately may be easier, especially when considering adding optimizations (which is apparently not well understood that a performance-oriented language such as Lua has not implemented it for many years), which makes arrays well-executed.

In addition, the point of flexibility is debatable. If a need arises for a more complex annotation, it is possible that you will also need polymorphism, in which case you just need to switch to objects with an array among other attributes.

+3
source share

Having separate types means that you can guarantee performance guarantees, and you know that you will have โ€œnormalโ€ semantics for things like slicing an array. If you have a unified system, you need to find out what operations, such as slicing, mean on sparse arrays.

+4
source share

As already mentioned, there are speed and complexity issues associated with having two separate types. However, one of the things that seems important to me with regard to the two types is that it expresses the intention of the data warehouse.

  • List - an ordered list of items. Elements and their order are data, keys exist only conceptually to describe the order of elements.
  • A map is a mapping of keys to values. The keys and values โ€‹โ€‹that they represent are data.

It should be noted that the keys are part of the data for the card, they are not for the list ... conceptually. When you select one data type over another, you indicate your intention.

I will add to the side that every language that uses a data type for lists and maps has certain ... troubles that arise with it. There are always certain concessions that must be made to allow a combination, and sometimes they can bite you. This is not a big deal at all, but it can be annoying.

0
source share

All Articles