Перейти на СУБД Cache. :D Там такое вообще не сделать чисто технически...

Как ни странно это физика школьный курс

dmitriymar, видно ты позабыл ту физику... :D
Это все равно что спросить:
- Чем чёрный отличается от кирзовый?
Применительно к солдатскому сапогу... :) Т.е. это просто разные характеристики одного "явления"...

Электри́ческий ток — упорядоченное нескомпенсированное движение свободных электрически заряженных частиц, например, под воздействием электрического поля.
Напряжение -это разность потенциалов. Потенциал-работа по перемещению электрона из бесконечности в данную точку поля.
И чего общего между движением и работой при движении?:)только в том что она есть

Или я тебя неправильно понял.

Возможно... :D

sky4uk, вам осталось спросить чем отличается B-tree от T-tree и JS программисты в эту тему больше не заудут ;)
Мне кажется, что у вас какие-то расплывчатые требования к специалисту.
Алгоритмы, графы, контейнеры, теорию компиляторов, знать конечно, хорошо, но покажите хоть одну книгу по JS, где это хоть как-то описывается.

я вам в личку написал

Народ, вы чего? Двусвязный список в JS - это список дочерних DOM-элементов.
Можно и свои списки использовать - удобно там, где есть большие списки любых объектов, поскольку очень легковесные операции вставки/удаления.

Это хеш. Вон отсюда, учить теорию.

Операции вставки в хеш тоже легковесны.

Ок, перед тем как я "вон отсюда", может скажешь, что в этом "хэше" в качестве ключа?

Хэши в силу своих свойств не поддерживают порядок следования элементов. Поэтому в хэш можно только добавить, но никак не вставить. Это подсказка к ответу на мой вопрос.

Извини за грубость, погорячился.

<div id="elem">
 бла-бла-бла,<span>бла-бла,</span> бла-бла, Mr. Freeman.
</div>
<script>
el= document.getElementById("elem");
alert(el.childNodes)// список дочерних узлов
alert(el.childNodes[0])// первый в списке, ключ - число.
</script>

Опять же, сделай ключами цифры и перебирай...

Уже остыл )
childNodes - не хеш, это коллекция (NodeList), при чем read-only. В обычном же хэше все ключи должны быть уникальны, каждому ключу может соответствовать только один элемент, и ключи эти не должны меняться по мере добавления/удаления элементов в/из хэша. Если вы вставите дочерний элемент, то у всех последующих элементов индекс в этой коллекции поменяется (увеличится на единицу), в этом она повторяет свойства массива, хотя таковым тоже не является, поскольку содержит ко всему прочему еще и ссылки на элементы по name и id, которые далеко не всегда уникальны, и опять же, в эту коллекцию нельзя делать вставку/удаление.
Физически элементы связанны между собой через nextChild, previousSibling, что и является двунаправленным связанным списком с началом в firstChild и концом в lastChild. А коллекция childNodes обновляется движком по мере вставки/удаления элементов и служит только в качестве вспомогательного механизма для доступа к элементам, но ни в коем случае не для хранения этих элементов.

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

Не факт. Есть различные способы разрешения коллизий в хеш-структурах, например, если для нескольких элементов ключи одинаковы, то ключ будет возвращать ссылку на связный список элементов с этими ключами("метод цепочек"). Но к JS это не относится.

К свойствам собственно хеша это не имеет никакого отношения. Если у массива это обусловлено способом хранения данных (они хранятся в памяти последовательно), то в случае с childNodes такие действия обусловлены логикой действия программы.

elem.parentNode.removeChild(elem)

nextChild и previousChild тоже не хранят элементы. Собственно, суть в том, что элемент - он просто есть. На него может быть сколько угодно ссылок - на элемент это не влияет (ну, почти). Если в C++, скажем, элементы добавляются в двусвязный список, а с удалением массива - исчезают, то здесь можно удалить хоть всех предков элемента - если на него будет ещё хоть одна ссылка, он будет жить. :D

Щито? Разрешение коллизий используется не для ключей, а для их хешей. Коллизии для ключей не рассматриваются в принципе. Считается, что все ключи уникальны, иначе непонятно, как различать элементы с одинаковыми ключами (Хотите хранить их все? Не вопрос — создавайте хеш-таблицу из список).
Никакие списки пользователю хеш-таблицы не возвращаются. Ему возвращается именно элемент, ассоциированный с нужным ключом.

Рассматриваются. В той же STL под C++ есть реализации ассоциативного массива, которые рассматривают добавление элементов с одинаковыми ключами - сохранение списка этих элементов.

Названия в студию.

multimap и multiset.

Вам w3 не авторитет?
И где здесь обращение к объекту childNodes? Вы обратились к объекту-хранителю связанного списка.
Ну во-первых, все эти механизмы не зависят от языка программирования.
Во-вторых в двусвязных списках ни где не используются массивы - только объекты и указатели, туда-сюда.
В-третьих, я разве писал, что nextChild и previousChild хранят элементы? Они хранят указатели на объекты элементов, как это и делается в любом двунаправленном списке. А коллекция childNodes является уже следствием этого списка, просто как дополнительный словарь-указатель (типа оглавления с закладками на уникальные name и id), и, подозреваю, что нигде во внутренних механизмах браузера не используется ни для рендеринга, ни для x-path обхода дерева. Поднимем исходники какого-нибудь браузера?

Почему не авторитет? childNodes - это коллекция, представленная хеш-таблицей. А не связным списком (аргументация: произвольное обращение невозможно в списке в силу его устройства. А childNodes прямой доступ - через индекс - предоставляет. Так что это более хеш, нежели список.) По этому пункту можно больше не спорить, имхо.

Это я так... Тут не буду спорить.

Это две разных структуры, которые нужны для разных целей. Я изначально спорил о том, что childNodes - это хеш-таблица. То, что перебор детей как двусвязного списка возможен - да, согласен. Сойдёмся на этом?

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

vk65535, вероятно, да... Но тут уж точно исходники браузеров поднимать придётся)

Япридумал еще классный метод отсева - повесить на столб намазанный маслом сапоги. Кто не сможет залезть без приспособлений - отсеян.

И в результате будет одно из двух: либо вакансией заинтересуется Чак Норрис (нет, не тот, что на этом форуме), либо ничего.

Наш точно не сдюжит... :haha:

ksa, ну да. Если у него спина от сидения за компом болит, то уж столб с маслом ему точно не по зубам. :D