Массивы как отдельный тип - PullRequest
8 голосов
/ 03 июля 2011

Некоторые языки сценариев, такие как Python и Javascript, имеют массивы (или списки) как отдельный тип данных из хэш-таблиц (словари, карты, объекты).В других языках сценариев, таких как PHP и Lua, массив - это просто хеш-таблица, ключи которой являются целыми числами.(Реализация может быть оптимизирована для этого особого случая, как это делается в текущей версии Lua, но это прозрачно для семантики языка.)

Какой подход лучше?

  1. Унифицированный подход более элегантен в том смысле, что он имеет одну вещь, а не две, хотя выигрыш не так велик, как может показаться на первый взгляд, поскольку вам все еще нужно иметь представление об итерации пов частности, цифровые клавиши.

  2. Единый подход, возможно, более гибкий.Вы можете начать с вложенных массивов, найти, что вам нужно аннотировать их другими вещами, и просто добавить аннотации, без необходимости переделывать структуры данных, чтобы чередовать массивы с хэш-таблицами.

  3. С точки зрения эффективности, это, кажется, в значительной степени стирка (при условии, что реализация оптимизируется для особого случая, как это делает Lua).

Чего мне не хватает?Есть ли у отдельного подхода какие-либо преимущества?

Ответы [ 3 ]

4 голосов
/ 03 июля 2011

Наличие отдельных типов означает, что вы можете давать гарантии производительности, и вы знаете, что у вас будет «нормальная» семантика для таких вещей, как нарезка массива. Если у вас единая система, вам нужно понять, что означают все операции, такие как нарезка, для разреженных массивов.

3 голосов
/ 03 июля 2011

Массив - это больше, чем таблица, намеренно ограниченная последовательными целочисленными ключами. Это последовательность , набор из n элементов (не пар ключ-значение, только значения) с четко определенным порядком. Это, на мой взгляд, структура данных, в которой нет места для дополнительных данных в виде нецелых ключей. Концептуально проще.

Кроме того, реализация этих двух по отдельности может быть проще, особенно при рассмотрении вопроса о добавлении оптимизации (что, по-видимому, достаточно неясно, так как ориентированный на производительность язык, такой как Lua, не реализовывал его в течение многих лет ), который делает массивы эффективными.

Кроме того, точка гибкость спорно. Если возникает необходимость в более сложной аннотации, вполне возможно, что вскоре вам также понадобится полиморфизм, и в этом случае вам следует просто переключиться на объекты с массивом среди других атрибутов.

0 голосов
/ 08 июля 2011

Как уже упоминалось, есть проблемы со скоростью и сложностью, связанные с наличием двух отдельных типов.Тем не менее, одна из вещей, которые я считаю важными в отношении двух типов, заключается в том, что он выражает намерение хранилища данных.

  • Список - это упорядоченный список элементов.Элементы и их порядок являются данными, ключи существуют только концептуально для описания порядка элементов.
  • Карта - это отображение ключей на значения.Ключи и значения, которые они представляют, являются данными.

Следует отметить, что ключи являются частью данных для карты, а не для списка ... концептуально.Когда вы выбираете один тип данных вместо другого, вы указываете свое намерение.

В дополнение я добавлю, что каждый язык, который разделяет тип данных для списков и карт, имеет определенные ... неприятности, которые приходятвместе с этим.Всегда есть определенные уступки, которые необходимо сделать, чтобы допустить комбинацию, и они могут иногда кусать вас.Как правило, это не имеет большого значения, но это может раздражать.

...