quirksmode.org: не в том, смысле, что это истина в последней инстанции

x-yuri,
Пожалуйста, не пишите в одну тему два поста подряд, редактируйте свои предыдущие сообщения, особенно, если разница во времени небольшая.

В тему обсуждения, с таким же успехом можно сказать, что строка это массив элементов типа string, а ведь это и выглядит так (я не уверен, что это специфицированная возможность и знаю, что в IE только charAt):

var a = "How do i do?";
// Имеет нумерованные элементы и длину:
alert([a[0], a[1], a[2], a.length]);

Но относительно терминологии JavaScript это будет, конечно же, неверно, хотя в среде C, например, нет такого отдельного типа "строка", но говоря о строках - подразумевают массив char'ов (даже в документациях).

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

Сайт хороший, но и на тысячи других сайтах имеются подобные описания-аналогии.

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

Вот лично вы - где услышали это определение? Я предположу - в PHP? Почему ж, он там хэш не называется? А-а, правильно, если копнуть глубже - то теоретическая структура (теоретическая!) "ассоциативный массив" может быть выполнена и не только хэш-таблицей. Почему ж в Руби или Per'e это называется хэш? Скорей всего там это выполнено хэш-таблицей? Так? Или не так? А что гадать - надо идти и смотреть исходники.

Т.е. все это очень и очень абстрактно (очень и очень!). В Си, например, являются ли эти структуры встроенными? Нет! Там - это лишь красивая и технологически обоснованная реализация, которая оперирует минимумом встроенных структур. Это все равно, что вы сейчас напишите объект dialog (вы-то будете знать, что это на самом деле), но потом будут спорить, что это "диалог", "окно", "модальное окно с искривленным ракурсом", "передвижной блок с данными", "интерактив с пользователем" и т.д. При этом, тот, кто это написал - тот и дал название. А далее, в разных сверх-языках, эта ваша реализация будет называться по-разному. А в каком-то языке, допишут свою идеологию и посчитают, что использование, например, понятия "интерактив с пользователем" может привести к неправильному пониманию этой новой идеологии; и решат использовать лишь понятие "окно".

в последней инстанции вообще ее нет ;) (для нас... пока.)

а в относительной инстанции, все же, более приоритетным является - http://javascript.ru/ecma

Поэтому, да - на прикладном уровне - можно называть хоть абырвалгом; если вы и ваш собеседник понимаете друг друга - это допустимо. Но, если при этом, вы еще и знаете об особенностях конкретной технологии, это еще 100 очков сразу вперед.

так чтобы именно ассоциативный массив - тогда в пхп, но до пхп я разбирался с Perl'ом, в котором хэши довольно похожи на ассоциативные массивы, если в детали не вдаваться (т.е. их назначение хранить пары ключ-значение)

хорошо, Dmitry A. Soshnikov, с точки зрения виджета dialog. Какая ему разница, что options - это объект? если он, допустим!, использует его только в таком ключе: this.options['option-name']? Или с точки зрения разработчика, который его создает?

Dmitry A. Soshnikov, мне очень понравилась фраза Кента Бека "любая методология основана на страхе" (http://www.maxkir.com/sd/methyperproject_RUS.htm). Давайте признаемся. Я боюсь запутаться, а вы боитесь, что вас неправильно поймут ;-) на этом даже можно прекратить дискуссию.

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

"Истина не может противоречить истине" (С) =) Фишка в разных "камерах наблюдения" (точки обзора, точки зрения) - на один и тот же объект, разные могут смотреть по-разному. Поэтому, если боитесь запутаться, можно не смотреть через альтернативные "углы обзора". Говоря о всем этом, касательно этой темы, я имею в виду - разную терминологию при описании сверх-абстрактных теоретических понятий. В принципе, да, если хотите, использование лаконичной терминологии, это - выдача определенной "камеры наблюдения". Но почему, скажите, создатель технологии не имеет права назвать это, как ему захотелось (грубо - выдать вам единственную "камеру наблюдения"), и почему другие (те, кто используют эту технологию) не должны использовать ее? Ответ тоже ясен - желание "осмотреться вокруг и по сторонам". А те, кто смотрел с другой "стороны", и их потом переводят на вашу "камеру наблюдения"? А вы говорите: "смотри, в моем телескопе линзы несколько другие, там, вроде, отведешь взгляд от объекта, а он все равно здесь! Но, мы же с тобой понимаем друг друга, поэтому можем это называть и твоей терминологией. Но, вообще, здесь это называется так-то и так-то".

Нет, я (в данном случае) не боюсь, что меня не правильно поймут, моя задача, как раз-таки, противоположная - не допустить, чтобы кто-то кого-то понимал не правильно.

В общем, данная тема ни в коем разе не прикладная, это "сферический конь в вакууме", это интересный "теоретический трёп", который некоторым (и мне в том числе) всегда интересен. Поэтому да, можно и закончить на этом, потому что никакого сенсорно-прикладного применения здесь нет (как не было и на протяжении 6-ти страниц) Спасибо. ;)

я просто стараюсь не думать о лишних деталях. Если мне моей текущей камеры не хватает, я иду в другую))

ну допустим не вас лично не поймут, но это детали)) но раз вы не боитесь, то и я тоже не боюсь)))) по крайней мере, в буквальном смысле этого слова