18.11.2011, 17:48
|
|
Модератор
|
|
Регистрация: 27.04.2010
Сообщений: 3,417
|
|
Сообщение от vk65535
|
Ок, перед тем как я "вон", может скажешь что в этом хэше в качестве ключа?
|
Извини за грубость, погорячился.
<div id="elem">
бла-бла-бла,<span>бла-бла,</span> бла-бла, Mr. Freeman.
</div>
<script>
el= document.getElementById("elem");
alert(el.childNodes)// список дочерних узлов
alert(el.childNodes[0])// первый в списке, ключ - число.
</script>
Сообщение от vk65535
|
Хэши в силу своих свойств не поддерживают порядок следования элементов. Это подсказка к ответу на мой вопрос.
|
Опять же, сделай ключами цифры и перебирай...
|
|
18.11.2011, 18:13
|
Кандидат Javascript-наук
|
|
Регистрация: 21.11.2008
Сообщений: 114
|
|
Уже остыл )
childNodes - не хеш, это коллекция ( NodeList), при чем read-only.
Сообщение от w3.org
|
abstraction of an ordered collection of nodes
|
В обычном же хэше все ключи должны быть уникальны, каждому ключу может соответствовать только один элемент, и ключи эти не должны меняться по мере добавления/удаления элементов в/из хэша. Если вы вставите дочерний элемент, то у всех последующих элементов индекс в этой коллекции поменяется (увеличится на единицу), в этом она повторяет свойства массива, хотя таковым тоже не является, поскольку содержит ко всему прочему еще и ссылки на элементы по name и id, которые далеко не всегда уникальны, и опять же, в эту коллекцию нельзя делать вставку/удаление.
Физически элементы связанны между собой через nextChild, previousSibling, что и является двунаправленным связанным списком с началом в firstChild и концом в lastChild. А коллекция childNodes обновляется движком по мере вставки/удаления элементов и служит только в качестве вспомогательного механизма для доступа к элементам, но ни в коем случае не для хранения этих элементов.
Последний раз редактировалось vk65535, 18.11.2011 в 18:57.
|
|
18.11.2011, 19:24
|
|
Модератор
|
|
Регистрация: 27.04.2010
Сообщений: 3,417
|
|
Сообщение от vk65535
|
не хеш, это коллекция
|
Кхм... Почитайте про коллекции на Википедии (ссылка туда). Коллекция - это просто условное название набора элементов, оно может быть представлено различными типами данных. В случае с childNodes она как раз таки представлена хешем.
Сообщение от vk65535
|
В обычном же хэше все ключи должны быть уникальны
|
Не факт. Есть различные способы разрешения коллизий в хеш-структурах, например, если для нескольких элементов ключи одинаковы, то ключ будет возвращать ссылку на связный список элементов с этими ключами("метод цепочек"). Но к JS это не относится.
Сообщение от vk65535
|
Если вы вставите дочерний элемент, то у всех последующих элементов индекс в этой коллекции поменяется (увеличится на единицу)
|
К свойствам собственно хеша это не имеет никакого отношения. Если у массива это обусловлено способом хранения данных (они хранятся в памяти последовательно), то в случае с childNodes такие действия обусловлены логикой действия программы.
Сообщение от vk65535
|
и опять же, в эту коллекцию нельзя делать вставку/удаление.
|
elem.parentNode.removeChild(elem)
Сообщение от vk65535
|
Физически элементы связанны между собой через nextChild, previousSibling, что и является двунаправленным связанным списком с началом в firstChild и концом в lastChild. А коллекция childNodes обновляется движком по мере вставки/удаления элементов и служит только в качестве вспомогательного механизма для доступа к элементам, но ни в коем случае не для хранения этих элементов.
|
nextChild и previousChild тоже не хранят элементы. Собственно, суть в том, что элемент - он просто есть. На него может быть сколько угодно ссылок - на элемент это не влияет (ну, почти). Если в C++, скажем, элементы добавляются в двусвязный список, а с удалением массива - исчезают, то здесь можно удалить хоть всех предков элемента - если на него будет ещё хоть одна ссылка, он будет жить.
|
|
18.11.2011, 20:04
|
|
⊞ Развернуть
|
|
Регистрация: 11.01.2010
Сообщений: 1,810
|
|
Сообщение от trikadin
|
Не факт. Есть различные способы разрешения коллизий в хеш-структурах, например, если для нескольких элементов ключи одинаковы, то ключ будет возвращать ссылку на связный список элементов с этими ключами("метод цепочек").
|
Щито? Разрешение коллизий используется не для ключей, а для их хешей. Коллизии для ключей не рассматриваются в принципе. Считается, что все ключи уникальны, иначе непонятно, как различать элементы с одинаковыми ключами (Хотите хранить их все? Не вопрос — создавайте хеш-таблицу из список).
Никакие списки пользователю хеш-таблицы не возвращаются. Ему возвращается именно элемент, ассоциированный с нужным ключом.
|
|
18.11.2011, 20:11
|
|
Модератор
|
|
Регистрация: 27.04.2010
Сообщений: 3,417
|
|
Сообщение от B@rmaley.e><e
|
Щито? Разрешение коллизий используется не для ключей, а для их хешей. Коллизии для ключей не рассматриваются в принципе. Считается, что все ключи уникальны, иначе непонятно, как различать элементы с одинаковыми ключами (Хотите хранить их все? Не вопрос — создавайте хеш-таблицу из список).
|
Рассматриваются. В той же STL под C++ есть реализации ассоциативного массива, которые рассматривают добавление элементов с одинаковыми ключами - сохранение списка этих элементов.
|
|
18.11.2011, 20:53
|
|
⊞ Развернуть
|
|
Регистрация: 11.01.2010
Сообщений: 1,810
|
|
Сообщение от trikadin
|
есть реализации ассоциативного массива
|
Названия в студию.
|
|
18.11.2011, 20:55
|
|
Модератор
|
|
Регистрация: 27.04.2010
Сообщений: 3,417
|
|
multimap и multiset.
|
|
18.11.2011, 21:19
|
Кандидат Javascript-наук
|
|
Регистрация: 21.11.2008
Сообщений: 114
|
|
Сообщение от trikadin
|
В случае с childNodes она как раз таки представлена хешем.
|
Вам w3 не авторитет?
Сообщение от Википедия
|
По реализации
На уровне реализации коллекция может представлять собой одну из следующих структур данных:
* Массив
* Односвязный список
* Двусвязный список
* Стек
* Хеш-таблица
* Битовый массив
|
Сообщение от trikadin
|
elem.parentNode.removeChild(elem)
|
И где здесь обращение к объекту childNodes? Вы обратились к объекту-хранителю связанного списка.
Сообщение от trikadin
|
nextChild и previousChild тоже не хранят элементы. Собственно, суть в том, что элемент - он просто есть. На него может быть сколько угодно ссылок - на элемент это не влияет (ну, почти). Если в C++, скажем, элементы добавляются в двусвязный список, а с удалением массива - исчезают, то здесь можно удалить хоть всех предков элемента - если на него будет ещё хоть одна ссылка, он будет жить.
|
Ну во-первых, все эти механизмы не зависят от языка программирования.
Во-вторых в двусвязных списках ни где не используются массивы - только объекты и указатели, туда-сюда.
В-третьих, я разве писал, что nextChild и previousChild хранят элементы? Они хранят указатели на объекты элементов, как это и делается в любом двунаправленном списке. А коллекция childNodes является уже следствием этого списка, просто как дополнительный словарь-указатель (типа оглавления с закладками на уникальные name и id), и, подозреваю, что нигде во внутренних механизмах браузера не используется ни для рендеринга, ни для x-path обхода дерева. Поднимем исходники какого-нибудь браузера?
|
|
18.11.2011, 21:29
|
|
Модератор
|
|
Регистрация: 27.04.2010
Сообщений: 3,417
|
|
Сообщение от vk65535
|
Вам w3 не авторитет?
|
Почему не авторитет? childNodes - это коллекция, представленная хеш-таблицей. А не связным списком (аргументация: произвольное обращение невозможно в списке в силу его устройства. А childNodes прямой доступ - через индекс - предоставляет. Так что это более хеш, нежели список.) По этому пункту можно больше не спорить, имхо.
Сообщение от vk65535
|
И где здесь обращение к объекту childNodes? Вы обратились к объекту-хранителю связанного списка.
|
Это я так... Тут не буду спорить.
Сообщение от vk65535
|
А коллекция childNodes является уже следствием этого списка, просто как дополнительный словарь-указатель
|
Это две разных структуры, которые нужны для разных целей. Я изначально спорил о том, что childNodes - это хеш-таблица. То, что перебор детей как двусвязного списка возможен - да, согласен. Сойдёмся на этом?
|
|
18.11.2011, 21:40
|
Кандидат Javascript-наук
|
|
Регистрация: 21.11.2008
Сообщений: 114
|
|
Ладно. Кстати, там не обязательно только хэш. Хэш там может быть для хранения значений по name и id, а для числовых индексов массив. Так было бы оптимальнее - чтоб не считать хэш-функции для числовых ключей. Все зависит от реализации.
|
|
|
|