хорошо, я хочу создать диалоговое окно с помощью jquery.dialog. Для этого мне нужно передать в качестве первого и единственного параметра набор опций, у каждой есть имя и значение, т.е. набор пар ключ-значение, т.е. ассоциативный массив. Для этого мне нужно знать названия опций и какие значения они могут принимать. К чему мне здесь прототипы и то, что в качестве ключа можно использовать функцию? Зачем мне лишние детали?

В качестве ключа использовать функцию? Это как?

функция - тип данных? в строку преобразовать можно? Вот вам и ключ

т.е. дело не в том, что в строку преобразовать можно, а в том, что "ключом в хеше может быть все, что угодно"

x-yuri,
разные функции могут давать одинаковый хеш.

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

это Dmitry A. Soshnikov про функции в качестве ключей упомянул, так что все такие вопросы - к нему

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

Нет, об этом я не говорил. Я говорил про то, что ключ может содержать функцию в качестве значения. И это было сказано на следующее предположение:

И я просто показал на примере Питона (да и в JS так же), что "переменная" является словарем (хэшем), хоть и "обладает поведением" (т.е. имеет функцию по некоторому ключу). Хотя, в Питоне так же - все, если говорить неделимо, является объектом.

Не просто "все, что угодно", а "все, что угодно, что хэшируемо" (и то - на уровне реализации). И тоже - говорил в данном пункте лишь в теории (но на примере Питона). JS это не касалось. В JS ключами могут быть только строки (ключи Array'я - тоже к строкам приводятся).

Да, прикладных задач эта дискуссия вряд ли коснется ;) здесь больше теоретический уклон.

Терминологии, несомненно, придерживаться стоит, причем, это и поможет избежать лишних деталей.

Чтобы подытожить, небольшая памятка по терминологии и основным принципам:

1. в JS есть объекты и примитивы;

2. примитивы при выполнении специфических операций преобразуются в
объекты;

3. исходя из 2) можно образно говорить, что "все в JS - объекты", однако, помнить, первые два пункта и знать, что пункт 3) - образный.

4. любой объект-контейнер может быть назван ассоциативным, поскольку может содержать пары "ключ => значение"

5. помнить, что ввиду делегирующей прототипной модели - ассоциация не точная, поэтому пункты 4 и 5 вообще употреблять не нужно :) (Хотя, тогда и в Питоне надо идти спрашивать, почему dict обособили от остальных объектов; там, как уже было показано, та же неоднозначность).

6. объекты, конкретно порожденные от конструкций Object, new __конструктор__ и {} (где __конструктор__ - объект-функция) принято (и согласно терминологии ECMA) называть объектами

7. объекты, порожденные от конструкций Array и [] принято (и согласно терминологии ECMA) называть массивами

8. объекты, порожденные от конструкций function и Function принято (и согласно терминологии ECMA) называть функциями или методами

10. согласно пункту 3), пункты 6), 7) и 8) можно называть объектами; это тоже будет верно, но уже будет более теоретический уклон, поскольку, обычно, в соответствующих местах, употребляются понятия из 6), 7) и 8)

11. если разговор не теоретический, а прикладной, никто не съест, если {} будет назван "ассоциативным массивом" / "хэшем" (или еще чем-то, услышанным в альтернативной технологии). Главное, опять, помнить и знать, - с таким успехом, все объекты являются "ассоциативными" и идеология в JS иная. Поэтому, чтобы "избежать лишних деталей", - лучше использовать лаконичную терминологию JS.

12. "Ассоциативный массив", "Разреженный массив", "Хэш-таблица" и т.д. - теоретические абстрактные понятия и структуры, стоящие выше конкретных технологий (JS, Python, Ruby, PHP и т.д.), поэтому однозначное использование этих определений - применительно к конкретным технологиям - размыто и не позволяет дать точную оценку.

Так и я вас спрашиваю, зачем мне нужно знать, что я работаю с объектом, если я не использую все его возможности? Они мне сейчас не нужны. Если у меня просто набор пар ключ-значение. А терминология Javascript добавляет лишние детали.

А что за специфичные "возможности"? И опять же, понятие объект - тоже образное, и в разных технологиях может иметь отличия (в частности, и в возможностях).

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

я приводил конкретный пример. Нужно создать dialog с помощью jQuery. При этом нужно передать набор опций через первый и единственный параметр. Никакие методы и прототипы мне в данный момент не нужны.

естественно, если человек не знает такого понятия, то можно либо его не употреблять, либо объяснить (если уверен, что не запутаешь его)

кстати, наткнулся недавно на статью http://www.quirksmode.org/js/associative.html (Objects as associative arrays), известный такой сайт

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-ти страниц) Спасибо. ;)

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

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