Что означает конструкция ?
 

Добрый деню. Нет времени читать целую книжку, нужно просто знать что значит эти две конструкции:

1. Calendar.setup = function (params) { ... }

2. что за странный формат аргументов:

Calendar.setup({
        inputField     :    "f_date_a",   // id of the input field
        ifFormat       :    "%Y-%m-%d %H:%M",       // format of the input field
        showsTime      :    true,
        timeFormat     :    "24",
        onUpdate       :    catcalc
    });

?

Спасибо!

попробую ответить, если неправильно сторожили поправят:
1. объекту Calendar назначается метод setup, который представляет собой функцию.
2. здесь в функцию предается массив данных (аргумент: значение)

Про формат аргументов не понял. Если имеется ввиду "%Y-%m-%d %H:%M" то это формат даты.

Не вводите человека в заблуждение. В функцию передаётся всего один аргумент - обьект(хэш). Краткая запись: {}. Внутри хеша описаны его параметры:
{param1:"value1",param2:"value2", и т.д.}

1. http://javascript.ru/tutorial/basic/functions
2. http://javascript.ru/tutorial/object/intro

из ссылок выше

Нет в JavaScript ассоциативных массивов. Это для похапэшников так пишут, чтобы доходило лучше.

А что есть? Терминология ECMA не определяет понятия ассоциативный массив, но, тем не менее, оба нативных объекта - порожденные и от Array и от Object - являются (в общей теории, а не в ECMA-определениях) ассоциативными массивами.

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

А Array от Object'а мало чем отличается: оба - нативные объекты, так же можно в array создавать нечисловые индексы (правда, это не воздействует на .length)

Dmitry A. Soshnikov,
а почему вы объекты типа String не называете ассоциативными массивами?

ivanmara, однако, не обращайте внимание на мои отстраненные от JS, теоретические рассуждения (они более общие). Касаемо же JavaScript следует понимать и говорить:

var a = [1, 2, 3]; - массив (имеет свойство .length, определены классические операции работы с массивами, фигурируют числовые (приводимые к строке) индексы; нечисловые - возможны, но не воздействуют на свойство .length)

var b = {a: 1, b: 2, 3: 3}; - объект (возможны числовые и нечисловые индексы-строки, нет свойства length, поскольку в JS - все от Object'a и свойство length "мешало" бы другим объектам)

а я и Object'ы не называю ассоциативными массивами, в целом, я беседую в рамках ECMA, но, рассуждая в теории структур - могу отклоняться от локальных определений ECMA (но только лишь для видения общих закономерностей, естественно, если разговор будет лишь об ECMA, поверьте, я использую их терминологию)

А вообще, и String можно назвать ассоциативным, если захотите:

var s = new String('1');
s['b'] = 10;
s['1'] = 20;
alert([s, s[1], s['b']]);

s['1'] == 20 // true. Есть пара "ключ => значение"? Есть. Есть ассоциация? Есть.

Да я-то как раз не хочу, это вы хотите. Просто объект класса Array является ассоциативным массивом настолько, насколько и любой другой объект. И даже примитивные значения плавно превращаются в них, стоит к ним точку приписать. Но говорят почему-то всегда только про Array.

если в теории структур - а почему бы и нет?

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

А вообще, если Вы загляните в исходники реализаций ECMA (например, в SpiderMonkey), то увидите, что понятия hash, hashTable, map (при создании нативных объектов) - там фигурируют.

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

ну "ассоциативный массив" - это более общее теоретическое понятие. А вот реализация этой теории может быть построена на хеш-таблицах. При этом стандартными операциями для ассоциативных массивов являются лишь добавление (obj.newKey = 10), поиск (for (var k in oj) { if (bla-bla)}) и удаление (delete obj.someKey).

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

Поиск в данном случае это obj.findKey.

почему? поиск значения по ключу? или определение вхождения ключа в структуру?

кстати, в php разницы между массив и ассоциативный массив нет (на уровне исходников - тоже хеши); там все - ассоциативный массив (но за размытие этих рамок пришлось в некоторых моментах пожертвовать)

{} - объект, [] - массив, function - функция - упрощённые термины, которыми оперирует (и правильно делает) большинство, а иначе будет:

function F(x) {
    var y = [];
    for (var i in x) {
        y[y.length] = x[i];
    }
    return y;
}

// передал в хэш! ассоциативный массив! и получил обратно объект!
F({a: 'preved', b: 'medved'});

> // передал в хэш!

F =)

> ассоциативный массив!

{} =)

> и получил обратно объект!

[] =)

Забавная каша =) и вместе с тем, получается, верная. Ну а что делать, если все это - нативный объект, который может содержать пары "ключ => значение"?

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

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

Хочу, однако, предостеречь всех, кто будет читать этот мой пост (и возможно, воспримет (ну, а вдруг!) его буквально). "Верная" в данном случае подразумевает соответствие объектов JS определенной теоретической структуре данных (ассоциативный массив) и касается только внутренних реализаций. В самом же JS, несмотря на то, что все это объект, выделяют терминологические понятия "массив" - [], "объект" - {}, "функцию" - function. И, говоря о JS, употребляются именно эти определения; также все три понятия могут быть определены как "объект", поскольку являются таковыми в терминологии ECMA.

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

Именно поэтому и уточняю, чтобы не было недоразумений.

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

Тогда нужно вернутся к истокам и определится с тем, что такое вообще ассоциативный массив. Что ты вкладываешь в это прилагательное по отношению к js?

Это такой же обычный абстрактный тип данных, не более. Кем-то так названный. Вообще, ассоциация (в философии) подразумевает, что по событию A, выдается событие B. Т.е. А - ключ к B. Отсюда назвали структуру - "ассоциативный массив", где ключ - любое "событие". В чем отличие от обычного массива? Формально - ни в чем. По событие "0" (индекс) массива - выдается "событие" "10" (значение). Физически же по факту - разница есть - в реализации.

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

И в Си (да и в Asm'e), например, - это всего лишь - "получить данные по адресу База + НомерСмещения * РазмерТипаДанных":

*(Base + Index)

при этом запись вида Base[Index] - всего лишь синтаксический сахар для этой конструкции (не более).

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

Если использовать просто понятие "ассоциативность", то разница (опять же - касаться внутренних реализаций не стоит) между "структурой", "объектом", и "ассоциативным массивом" - не значительная - и там, и там, и там - мы имеем: "найди в Оболочке (Базе) событие B, вот тебе для этого ключ А". Физически, конечно все это отличается (структура, например, статическая, тогда как в "ассоциативный массив" можно добавлять значения динамически; хотя, динамичность - здесь, конечно, не главное).

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

Я-то уж не вкладываю, я писал уже, что я не использую понятие "ассоциативный массив" вообще, когда говорю о JS, я говорю "объект". Но всегда готов найти (и показать - кому это интересно) сходство с этой теоретической структурой. Только лишь абстрактно: все JS объекты - есть нечто, что может хранить ассоциации (по событию (ключу, полю, слоту, свойству и т.д.) "А" выдавать событие (значение) "B"). И если этот ассоциативный объект динамически изменяем - нет возможности утверждать, что это не может подпадать под любые определения, которые также реализуют это поведение (напоминает Duck Typing =)). С другой стороны - если идет разговор о JS, то, естественно, нужно использовать терминологию JS. Просто я, когда слышу от кого-то "ассоциативный массив", поправляю (но не категорично отрубаю, что нет в JS этого), что "в JS терминология (и, что более важно, - идеология) другая, здесь все является объектом, но в целом это напоминает то, что вы видели под терминологией хэш или ассоциативный массив в других реализациях; и если вы хотите изучать именно js, то, когда будете говорить о js - стоит говорить в его терминологии. К тому же, это и физически может отличаться". И все - человек сразу врубается и уже не устраивает холиворы (ну а как же - он видел "то же самое" в других языках и там это называлось так, а тут ему утверждают обратное :))

В таком философском ракурсе можно считать, что все объекты - это "некая абстрактная штуковина", это тоже правильно, только не помогает оценить и понять особенности ;). Ну, какая может быть ассоциация между А и В, если за спиной стоит отряд прототипов? Никакая. Динамическое изменение приводит к изменению длины массива? Может да, а может нет. Есть отличие по синтаксису доступа между массивом vs. объектом? Нет, конечно. Тогда в чём "ассоциативность"? В динамическом изменении в рантайм? В произвольности "ключей"? Это свойства любого объекта. Массивы терминологически выделены из этой общей кучи не за это, а в связи с определённым поведением, не имеющим ничего общего с "ассоциативностью/хешестью"...

Прилагательные массиву не нужны (кроме может специфичных вроде "0-относительный массив", "разреженный массив" и т.п.), они его не очерчивают, не выделяют, его вообще вредно выделять, в крайнем случае можно сказать, что все объекты (все!) в js ассоциативны, только не понятно, что это объясняет, каждый думает о своём. Кто-то начинает видеть два вида массивов, кто-то хеши в своём разумении, кто-то проверяет свойства массива в стиле typeof i == 'number' и так далее...

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

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

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

Почему отстранённые? Ты пару не задавал, массив/объект "пустой", а она (пара) уже есть, ты пару удалил, а она снова есть (имена совпали), ты её пошёл в прототипе удалил, а она снова есть (снова имена совпали), прочитал из прототипа, положил в объект и т.д. Дело-то не ожидании значения по "ключу", дело в ожидании заданного/правильного значения, дело в мнимой произвольности "ключа", в невозможности быть уверенным в паре, невозможности однозначно удалить пару, в сложности перебора и т.д. Идеология такая не-строгая-делегирующая, ну, сколько пар забито у "пустого" объекта? Их надо все пересмотреть, чтоб определить для себя границы произвольности "ключей", чего задавать, чего не перекрывать? Длина массива ничего не говорит об ассоциациях и т.д. и т.п.

зы Можно поступить проще - взять признанное определение ассоциативного массива (несколько) определений и посмотреть, удовлетворяют ли объекты js этому (этим) определениям. Если определение не будет космически-обобщённо-туманным, то ничего не выйдет. ;)

Да, здесь однозначно, определение точной ассоциативности рушится, в том плане что, "удалил, а оно опять тут".

Можно, правда, частный случай задать (ради теорий о точной ассоциативности), но это не меняет факта, что точной ассоциации здесь нет:

obj.get = function(key) {
  if (obj.hasOwnProperty(key)) {
    return obj[key];
  }
  return null;
};

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

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

Ты всё равно не хочешь идти по простому пути противопоставления мифам таких же лозунгов, может это и не однозначно, зато работает с той же силой, что и миф:

- Ассоциативных массивов нет!
- Классов нет!
- Хешей нет!
- Не всё является объектом!
- eval - зло!
- Ненавязчивого javascript-a в природе не существует!
- ...чего там я ещё забыл...

;)

Zeroglif,

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

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

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

А в целом - беседа с тобой, как всегда, не проходит зря ;)

а к чему собственно спор пришел?

ну т.е. может итоги подвести? какие доводы за/против?

x-yuri, какой спор? Спора однозначно никакого не было.

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

не было спора? я понял, это была светская беседа высокообразованных людей ;-)

какие-то выводы слишком абстрактные получились. Ведь на самом деле, Вы говорите, что есть абстрактное определение ассоциативного массива (множество пар ключ-значение), а есть терминология js (ассоциативный массив там отсутствует). Zeroglif же говорит, что есть терминология js, а все остальное не нужно и только запутывает. Т.е. Вас интересует "истина", у Zeroglif же более практический подход к делу.

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

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

Интересно хеши в JavaScript в памяти организованы в виде хеш-таблиц?

Зависит от реализаций. Хеш - всего лишь терминология, подразумевающая разреженный массив, выполненный с помощью хеш-таблицы. К примеру, в Python он называется "словарь" (dictionary):

a = dict(a=10, b=20)

# равносильно
b = {'a': 10, 'b': 20}

print(a['a'], b['a']) # 10, 10

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

# класс A, наследуемый от класса "словарь" (dict)
class A(dict): pass

# можно было объявить методы, для доступа к свойствам
# тогда бы можно было использовать обе конструкции a.prop и a['prop']

a = A() # инстанс

a.a = 10 # 10
A.a = 20 # классовое свойство, будет следующим в цепи поиска, если родное свойство не будет найдено

print a.a # 10
del a.a # удаляем
print a.a # 20 - удалили, а оно опять тут

Сложно здесь говорить однозначно, в виду размытости определений и понятий, стоящими за этими определениями; если удобно употреблять понятие "ассоциативный массив" - можно употреблять, но, относительно терминологии ECMA, это будет не верно (как не существует и понятия хеш в ней). Любой объект из ECMA подпадает под "ассоциативность". Между тем, на уровне реализаций - и "объект" и "массив" JS могут является и (из фундаментальных определений) "ассоциативным массивом", и (он же, подпадает по определение) - "разреженным массивом", и "хешем", и, "map'ом", и "деревом поиска" и (просто) "объектом" и т.д.

Да там дело даже не в вызове методов. В том же Python'e - словарь может хранить по ключам методы:

a = {
  'b': 10
  'c': lambda: 20
}
a['b'] # 10
a['c']() # 20

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

- массив
- объект
- разреженный массив
- ассоциативный массив
- хеш
- список
- словарь
- map
- др.

Но, как видно из примера выше с Python'ом, - объект, порожденный от класса, наследуемого от класса "dict" (т.е. объект является "словарем"/ассоциативным массивом) также не однозначен в своей ассоциативности.

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

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

но спорить на тему, что такое ассоциативный массив очень сложно, потому что я не знаю достоверного источника информациипо этому вопросу. Я видел 2 мнения: 1) набор ассоциаций, 2) массив, у которого в качестве индексов могут быть не только числа. Скорее всего было так: сначала массив пропатчили, и у него появилась возможность использовать не только числа в качестве индексов. А потом его пропатчили так, что его и не узнать уже ;-) все что осталось, так это возможность получить значение по ключу.

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

какая разница: методы - элементы массива, а не ключи

А в каких языках используется именно эта терминология (ассоциативный массив)? Точно в PHP, а еще где? В JavaScript - объекты (Object, Array, String, RegExp, Boolean, Function и т.д.), в Ruby - Hash'ы (тоже все объекты, но выделен класс Hash), в Python - dict'ы (тоже все объекты - см. пример выше, но выделен класс dict), в Java - HashMap'ы. При этом, все это, опять обобщённо может называться "ассоциативный массив".

Насчет "если переменная обладает поведением - то это объект" - тоже - лишь личная версия. Повторю - в Python'e (как и в JS) - по ключу может быть функция, но вместе с тем это остается словарем (объектом-словарем). В Ruby, например, ключом может быть другой Hash:

a = {:a => 1, :b => 2}
b = {a => 3, :c => 4} #  {{:a=>1, :b=>2}=>3, :c=>4}

Вообще, ключом в хеше может быть все, что угодно, что хешируемо (hashable), т.е. возвращается значение, вычисленное некой хеш-функцией (из глоссария Питона - http://docs.python.org/3.0/glossary.html#term-hashable)

В общем, что можно сказать точно - так это то, что это очень размыто и точно сказать очень сложно.

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

А в Википедии, тоже часто субъективные статьи, так в Associative arrays некто пишет, что в JS все контейнеры - ассоциативные эррэи, в JavaScript syntax (там же, Википедия) уже кто-то пишет: "JavaScript objects are often mistakenly described as associative arrays or hashes, but they are neither." Класс, ага - и дальше ни слова об этом =) Так и хочется спросить - почему? Откуда он это взял? Откуда взяли те, кто писал статью про Associative arrays? Получается, каждый пишет, что захочет? Но что-то же должно быть эталоном? Вероятно, все же, таковым должна являться спецификация технологии (и в данном случае, это ECMA). Поэтому, на вопрос "Откуда он это взял?" - ответ будет - "из спецификации, там такого нет". Если же копать глубже - однозначных ответов не будет.

Про разреженные массивы можно тут (на русском) почитать - http://lord-n.narod.ru/download/book...po_C/23/23.htm, и, в частности, реализация на хеш-таблицах - http://lord-n.narod.ru/download/book..._C/23/2305.htm; и в русской Википедии - разрежённый массив, который ссылается на "ассоциативный массив", как реализацию (в свою очередь, ассоциативный массив ссылается на хеш-таблицу, как на одну из реализаций).