M Sardar

Тема разделена, оригинал тут: http://forum.vingrad.ru/forum/topic-197524.html

Как минимум, SpiderMonkey различает то, каким образом вызывается функция – как метод какого-либо объекта или нет:
JS CallFunction
JS CallFunctionName
JS CallFunctionValue


Сколько ни старался, но так и не смог найти (там, у них) такого определения, как "вызов функции в контексте объекта". Все, что попадается, выглядит совсем иначе:

Т.е. или "функция вызывается на каком-то объекте", или "объект, на котором вызывается метод". Вообще, упрощенно, на js вызов метода выглядит (как мне представляется на сегодняшний день) вот так:

Да и в ECMAScript Language Specification оно именно так и выглядит:

, где Result(3) - это js-значение (Function object), а Result(7) - это тот самый объект (а может быть и null), на котором вызвана функция.

Да куда уж жестче, если значение this уже не изменить? И определено оно будет еще до вызова.

Просто переменная, где то выше инициализированная.


Детали реализации. Различий как между вызовами как "метод" или "просто функция" - нет, это всегда "как метод", всегда передаётся на ком вызвали. Три нативных функции это разный способ достать JS функцию - либо поиск функции по имени, либо уже готовый объект функции, либо обёрнутый в ссылку. В реализации на Haskell к примеру это будет одна функция, правда при компиляции тоже сделает тучу вариантов (скрыто от тебя). Хотя по моему уже была дискуссия, где выявилось что ECMA разделяет декларации функций 


и функции-closure как значения


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


Ты привёл пример синтаксиса (как написать), я говорю о семантике (что означает). Передача функции объекта, на котором вызвали функцию == "вызвать функцию в контексте объекта". По крайней мере мы так среди своих в универе говорим, не формально 


Опять детали реализации. Не важно как интерпретатор получит ссылку на объект, будет ли искать его постоянно или положит на стек - для тебя, в синтаксисе (в тексте) всё одно. Да, когда встретим:


Где объект функции держит свой local_context где она была определена, который отведён от боле верхнего до global (здесь global - объект из ECMA, в JS это window). Можно усложнить, можно упростить, зависит от языка и требований (thread-safe к примеру). К самому JS это отношения не имеет, функция всегда вызывается на каком то объекте, где global.func(); и func(); идентичны. Функция не имеет привязки к объекту на подобии

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


В универе – это одно, а здесь в результате мы видим то, что ни в ECMAScript Language, ни где-то поблизости днем с огнем не найти (я имею ввиду такой термин, как slot, например):

Приходится ломать голову над трактовкой – то ли это что-то новенькое в ES, то ли это метафора, то ли речь идет об адресации к динамической памяти (к которой сам ES вообще никакого отношения не имеет).


Сам context она не держит. Как я уже писал, контекст – это многогранная информация, которой нет места в scope chain. Если представить это так, как определено в спецификации языка, то в [[Scope]] property функции должна быть цепочка, состоящая из activation objects окружения, в котором функция была создана (там же могут оказаться те, что были добавлены усилиями with или catch). И никакого "своего local_context, где она была определена".
Взять хотя бы this value, ассоциирующееся с выполняемым контекстом. Этого значения нет и быть не может в [[Scope]] property функции.


window === global:

Более того, global object может быть доступен благодаря this keyword в глобальном контексте. С помощью того же this объект global можно заполучить в любом другом контексте таким образом:



Отнюдь нет. Во втором случае идентификатор func может оказаться методом любого объекта из scope chain активного контекста выполнения, и им может оказаться вовсе не global.


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

Т.е речь шла непосредственно о вызове на некотором объекте, и тут уж привязка достаточно жесткая.

AKS, может ну его к черту этого сферического коня в вакууме? Семантика, предложенная Sardar, вполне оправданна и помогает понять суть. К чему эти высокофилософские споры?

smartov, 

не мешай, я только попкорн принёс и уселся поудобней...   

Не надо, так не надо. Я не спорить хотел, а выяснить то, как ближе к "телу". Я ведь на 100% не уверен, что моя формулировка правильная. Мне самому нужно понять, как должно быть. Форум – это хорошая для меня возможность сделать это...
Кстати, а откуда этот "сферический конь в вакууме"? Что это на самом деле? Персонаж из анекдота?

imho, это из попытки физика выдать определение лошадинной силы... Откуда-то из "физики шутят" или еще более ранних...

ЕСли попридираться не по делу, то вот это утверждение несколько спорное  В жизни есть , к примеру WSH, в котором объекта window нет вообще, а javascript - есть... есть "встраиваемый" в приложения Javascript, в котором бывает все, включая черта в ступе...

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


Не по делу – это любой может, а Вы по делу попробуйте. Смотрите за ходом:

, далее, в контексте "в JS это window":

и подтверждение из ES:

, т.е. если уж есть window, то это и есть global.

AKS, 

Да. Сначала из анекдота. Потом... Ну в общем нарицательным стало. Аналог "бессмысленная, в приложении к практике, тема"  

Ну да, в случае если он есть... А если нет - то что - это уже и не JavaScript вовсе? Или вам кажется, что ES придумывался исключительно для использования внутри броузеров и с обязательной поддержкой 

  ?


Это сообщение отредактировал(а) ksnk - 29.2.2008, 13:33

Так, давай определимся с понятием контекста. Есть локальный контекст - это набор всех локальных переменных определённых в функции (var выражения). Есть  унаследованный контекст (у тебя scope chain) - это набор всех переменных, видимых на момент определения (создания нового instance) функции - по сути локальный контекст "родительской" функции (представим что самый внешний контекст это локальный контекст гипотетической функции run() {  здесь код самого верхнего уровня }.

Контекст объекта - это набор всех его slot'ов (термин из Smaltalk, откуда прототипные объектное программирование взяло начало). В мире где "методы" и "переменные" объекта находятся в одном адресном пространстве - такие "поля" называются slot'ами. Я думаю ясно почему это удобней, вместо воображаемого разделения на "переменные" и "методы" объекта (некоторые воображают даже классы в JS).

Контекст объекта == this внутри функции, позволяет обращаться к полям (slots) obъекта - задаётся программистом при вызове функции (да, именно программист говорит на каком объекте вызвать функцию, .func() - лишь удобный синтаксис). Объектов масса - значит и разных контекстов масса.

Локальный контекст - создаётся каждый раз при вызове функции, при чём для каждого рекурсивного вызова (а также для каждого треда в multi-threaded движках) создаётся новы экземпляр контекста.

Наследуемый контекст (ECMA: scope chain) - связан с конкретным instance функции. От одной функции можно породить массу instance, каждый будет связан со своим наследуемым контекстом, который существовал в момент когда интерпретатор создавал этот instance - другими словами каждая функция это closure (почти, это дело можно оптимизировать + ECMA по моему различает понятия функция и closure из-за немного разной видимости переменных).

Ну и наконец - контекст == (map(name) => value) - обычно реализуемого хеш-таблицей. Теперь давай опираться от этих понятий и не путать вещи.


А теперь давай отбросим фарисейство и воспользуемся человеческой соображаловкой. Я не использую терминологию ECMA, т.к. перевожу термины на русский по смыслу.


Говорим об одном и том же разными терминами (тупо переименуй абстрактное контекст на более конкретный scope chain).


Используя global подразумевал переменную, содержащую именно объект global. Дописывать ", где переменная global содержит объект global" в не формальном общении для меня выглядит дико 


Речь шла почему object.method даст функцию не связанную с object. Совершенно естественно, что интерпретатор на момент вызова функции найдёт объект и передаст его функции как this, но тебе в языке это принесёт такую же пользу, как знать, что Земля круглая. А ещё можно построить автомат, в котором object  (, где object содержит объект object, упомянутый в первом предложении   ) будет "закодирован" в набор состояний и тогда понятие this в интерпретаторе (в native run-time, не в семантике JS ;-) ) вообще исчезнет. Всё зависит от реализации.


Мантра:

Что бы было ясно: программиста интересует можно ли создать функцию, что будет жёстко привязана к конкретному объекту, где жёсткая привязка позволяет вызвать функцию без указания объекта, на ком вызываем и тем не менее ссылка this будет указывать на оригинальный объект.

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

Но ведь в в N микросекунд, в которые интерпретатор выполняет функцию, он ведь "знает" объект на ком вызвали, значит в этот момент есть"жёсткая привязка"!
Ответ: термин "жёсткая привязка" понят не правильно, реализация тут не при чём, обсуждаем специфику языка. В реализации само понятие объект может отсутствовать, а ссылок не явных (требуемых в разные моменты времени) может быть вообще не ограниченное количество.

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

Перестать задумываться о реализации JS движка, ведь в разных языках и окружениях по разному. Используя общий термин контекст, я к примеру не имею в виду JSContext из SpiderMonkey. Если конвертнуть интерпретатор в машину Тьюринга, то детали из SpiderMonkey вообще потеряют смысл - заметим, что семантика JS при этом не изменится 


P.S. извиняюсь, за жёсткий ответ, просто считаю что спор уходит в тупик, когда скатывается до различий в терминологии.

Я ведь написал, что window === global. Что не понятно? И разве я писал что-то об отсутствии window? Вроде бы указал на автора формулы "global - объект из ECMA, в JS это window", так почему ко мне вопросы?


Это не только "var выражения". Это еще и arguments object, и формальные параметры, и объявленные функции, и т.д., и т.п. 


Это не у меня, это в ECMAScript Language Specification. 


Опираясь на ваши же рассуждения, что локальный контекст – это набор локальных переменных, можно сказать, что унаследованный контекст не является лишь локальным контекстом "родительской" функции.


Зачем представлять по-своему то, что уже давно представлено? Чтобы подогнать под свою философию?


Не аргумент.


Я как-раз так не думаю.


Это еще при чем? 


Мне не ясно – для чего подобные оговорки? Мы в каком разделе беседуем?


???


???


О каких именно понятиях речь? Пока передо мной лишь бессвязная каша – локальные/наследуемые/наборы слотов/this внутри функции/хеш-таблицы. 


В очередной раз не понимаю, на этот раз – причем тут фарисейство? Вы или выбирайте выражения, или не используйте тех, смысл которых Вам не ясен.


А я напротив предлагаю воспользоваться существующими определениями, не пытаясь перевести их на любой другой язык. Подобные попытки всегда неудачны.


Очередное определение контекста? Так что же это, в конце концов? И как это последнее, с вашим слов тупо переименованное, увязать с вызовом функции в контексте объекта?


Не все могут, также как smartov, понимать Вас с полуслова. Лично у меня не настолько развитая интуиция. Так что пишите сразу, как есть, чтобы потом не оправдываться.


Любые детали полезны, также как и знание того, что Земля круглая. 


Да уж...


Да не это его интересовало, господи!


Ответ простой - нужно учиться искусству общения.


Обсуждать, используя свою доморощенную терминологию? Насколько продуктивным может быть такое обсуждение?


Даже если собеседник ошибается и не хочет признавать своих ошибок? В чем смысл обсуждения, если заблуждающийся упирается руками и ногами?


Причем тут разные языки и окружения? Есть ECMAScript Language Specification, есть реализации, претендующие на соответствие спецификации – о них и речь. Все остальное, а именно чьи-либо пространные рассуждения, к примеру о машине Тьюринга, не представляет для конструктивной дискуссии ни малейшего интереса.


SpiderMonkey был упомянут, как незначительная частность, или как следствие, если угодно.


Не стоит извинений. Эмоции - они от недостатка аргументов.

Это сообщение отредактировал(а) AKS - 29.2.2008, 17:58

Ну, чтобы придать конкретности - вот та "реальность", для которой мне приходится чего-то писать

результат

Что такое у меня this я так и не разобрался, документацию читать лень, да и потребности пока не вижу... ;-) Что такое global или window в моей "реальности" - вообще неопределено... Тем не менее это самый настоящий JavaScript. Впрочем формула window===global в ней, хоть и бессмысленна, но спарведлива 

Это почему же? Вчитайся в мой текст получше. Термин "лишь" - не ограничивает пользователей контекста только функцией, к которой контекст принадлежит, если что...


Странный выпад... Да, не опираюсь на стандарт ECMA дословно, смысл то идентичный. Мало того, в реализации действительно удобно представить самый внешний контекст как просто локальный контекст гипотетической run(). Может приведёшь, что ECMA говорит по этому поводу и где я был не прав?


Ну это аргумент обиженного малыша, если честно   В чём различия между "простыми" переменными (содержит число к примеру) и "методами" (переменная содержит функцию)?  Только по существу, т.к. на концептуальном уровне для человека пришедшего с ООП это действительно удобно. Увы понятие "концептуальный уровень" - есть инструмент, для лучшего восприятия семантики. Например узнав что такое классы и instaces в Haskell у обычного ООП программиста "расплавятся мозги", проверенно на себе   , но поняв, чувствуешь себя как заново родился 


Не формальное обсуждение JS. Суть этого топа, по моему было решить - есть ли какая-либо жёсткая привязка функции к объекту, такая, что имея на руках только функцию, можно достать объект, к которому эта функция принадлежит - правда скатываемся до выяснения, чья же терминология лучше и как это кощунственно переводить термины ECMA по смыслу     Попутно нырнули в дреби SpiderMonkey, узнали что таки this всегда при вызове функции используется, а три C'шных функции нужны для разного доступа к функции. Ну ещё узнали, что при общении нужно точно указывать, когда говорим о ссылке, а когда о конкретном значении (соглашусь, полезное качество  ).


Где я ошибаюсь? До сих пор наш диалог напоминает:



Предлагаю взять мои утверждения и опровергнуть. Нет, не доказать, что я не copy-paste термины из спецификации ECMA, а то что изменил смысл терминов. Или хотя бы заблуждаюсь в вопросе ссылок.



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

Добавлено через 2 минуты и 38 секунд
ksnk, global (объект, а не переменная с именем "global" если что   ), действительно существует в ECMAScript окружении. Оригинальный "браузерный" JS в этом плане отличается, там используется DOM 0 window для этих целей (DOM 0 - общепризнанный термин "унаследованных" window, document и т.д. если что    )

Global Object



Вчитываюсь:


Ага, вары – локальный контекст. Дальше:


Унаследованный контекст – локальный контекст "родительской" функции. А что такое локальный контекст "родительской" функции? Согласно Вам - это вары "родительской" функции. 
Вот я и пишу, что не только лишь.


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


Я написал лишь то, что написал, и ни слова о правых и неправых.
Почему не тянет на гипотетической run()? Хотя бы потому, что есть существенные отличия – отсутствует arguments object и формальные параметры. 


Этот человек начнет для своего удобства искать классы и т.д. Что прикажете делать? Найти и показать их ему? 
Речь не об удобстве – речь о конкретных терминах.


Я не скатываюсь. Я не собирался выяснять, чья лучше, а чья хуже. Посмотрите, с чего я начал: "А вот там вроде что-то такое есть", "А вот этого я никак найти не могу", "А вот в доках все как-то по-другому".
И мне не нужна моя терминология. Я пытаюсь узнать то, как должно быть. Читали, что я ответил smartov?


Да хотя бы с closures. То Вы пишите, что "ECMA разделяет декларации функций и функции-closure как значения":

, то вдруг "каждая функция это closure". 


Каких еще ссылок?


А что так? Какие есть еще соображения по теме? Я же написал, что я не уверен на 100%, и чтобы понять, нужно обсуждение. Вот, к примеру, у тех, кто пишет Mozilla’вские доки (this Operator) представление почти такое же, как у Вас:

А разве не так? Приведи пример, лучше кодом. Не стоит мелочиться на аргументы функции, я о них помню и наверное каждый из присутствующих.


А чем аргументы отличаются от точно таких же локальных переменных, объявленных var? Чисто технически обычно не делают различий, namespace то ведь один. Приведи пример, где аргументы функции обладают какими-то особыми свойствами, которых нет у переменных объявленных var.


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


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




Был когда то древний спор, быть может даже с тобой, о различиях объявления функций function name ()  и var name = function() - выяснилось, что различий есть, по моему в видимости других переменых. Именно в этом ECMA разделяла эти понятия, хотя могу ошибаться. Помню что это никого задеть не может, на практике оба варианта дают эквивалентный (повторяю на практике, не формально, не дотошно, перечитать снова) результат. Хорошо бы поднять эту тему, а то самому интересно, да поиск у нас на форуме отказывается её найти.

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


Ну как же, вопрос был есть ли жёсткая привязка функции к объекту. Отсюда пошёл спор, что я пользуюсь не терминами ECMA (разве? ;-) ). Впрочем перечитал топ, так и не понял, утверждаешь ли ты что я прав и ли не прав?   


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


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

Sardar, 
бог с ней с терминологией, я, например, с удовольствием использую термин "slot", особенно рассказывая о делегировании в javascript. Зря тут AKS тебя за это кусает, но раз ты просишь указать на ошибки, то держи:

- в js методов не существует
Существует. Год назад приводил тебе текст стандарта, методы есть, другой вопрос, что у них нет жёсткой связи. Вот как нельзя говорить, что в js нет наследования по причине отсутствия классов, так нельзя и отменять вовсе методы по причине некоторой анархии. Но логика твоя по существу понятна, только доведена она с некоторой категоричностью.   

- любая функция вызывается в контексте некоторого объекта
Тоже категорично. Не любая. В контексте какого объекта вызывается анонимная функция?

- this будет указывать на этот объект
Вызови анонимную функцию или выражение, или вложенную именованную функцию, где там точное указание на вызывающий объект, значением this станет условно "чужой" объект (window) , а не реальный "владелец" метода/свойства/слота.

- это closure, мы сохраняем весь контекст на момент создания новой функции
Не весь контекст, а чужой scope chain, контекст  - более широкое понятие, с которым ассоциирован this, arguments object, scope chain. В твоей терминологии мы сохраняем как бы "наследуемый" контекст.

- набор всех локальных переменных определённых в функции (var выражения)
Ты забыл про формальные параметры и объявленные функции. Можно было бы не придираться, но ты акцентировал внимание на варах.

- набор всех переменных, видимых на момент определения
Типичная ошибка. Переменные не видны, равно как и их значения, только объекты в scope chain. На момент создания функции переменной вообще может не быть или её удалят уже после создания функции, замыкание это вообще не колышет.

- переименуй абстрактное контекст на более конкретный scope chain
Нельзя, это разные ж вещи, см. ES 10.1.4.

Пример, демонстрирующий, что вложенная функция получит в свое распоряжение не только переменные "родительской" функции:



Дело не в том, чем отличаются вары от аргументов. Речь об отличии global object от предложенного вами "внешний контекст это локальный контекст гипотетической функции run()" К чему эти ассоциации? Есть совершенно понятное определение этого объекта, подчеркнута его уникальность – зачем огород городить?


Хоть вопрос и не к месту, тем не менее придумал вот такой пример (тоже не совсем к месту, но кое-какие отличия он все же демонстрирует, и их нужно увидеть):

Т.к. переменная а создана в eval code, то ее можно удалить. Почему такую же переменную нельзя удалить в этом случае:

?


Это что за код должен быть? 
Вообще, на мой взгляд, между понятиями функция и closure итак есть совершенно очевидная разница. 


Я уже написал, что мне не ясно. 
Я не нахожу пока уверенных объяснений, что фраза "вызов функции в контексте объекта" имеет какой-то смысл.
Я не понимаю, зачем нужно утверждать, что нет методов. К примеру, согласно спецификации Array.prototype.toString, Array.prototype.toLocaleString могут быть вызваны только как методы Array object. Или Function.prototype.toString также может быть вызван только как метод Function object.
И т.д...

Другими словами метод существует на уровне концепции, так проще понять ООП программисту. О чём я и говорил 

Не лучший пример с википедии:

Ключевое слово exclusively, чего не наблюдаем в JS. Метод - операция связанная с конкретным объектом (данные), либо группой однотипных объектов. В JS этого "физически" нет, хотя на уровне логики мы обычно не мешаем "методы" разных объектов между собой.


Наглядным примером видим:

Что верно, не важно какая функция, важно как она была вызвана. Если без указания объекта - то по дефолту им будет global.


В этом и был смысл топа.  Нет у функции привязки к "владельцу", т.к. "метод" - штука только в твоём воображении (концепция) 
На момент вызова ты явно указываешь на ком вызывается метод.


Признаюсь, использую понятие контекст очень широко, поэтому в последних постах стал применят по несколько слов, "локальный контекст", "контекст объекта" и т.д. Опять же, связать context с (this, arguments object, scope chain) - терминология ECMA, не обязательно нести это вне документа (да, слабый аргумент   )


Забыл поставить "и т.д.", что обычно делаю. Если бы писал спецификацию, обязательно бы указал. Мы же тут в беседе, признаться в первый раз в жизни так долго оправдываюсь за использованные термины и "недоговорки" 


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

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

ECMA определяет в первую очередь синтаксис и семантику. Они имеют право разделять разные источники пар (имя => значение), но оговаривают, что это всё в одном namespace. Как программисту тебе тогда по барабану откуда пришли переменные, если они в одном namespace. Назвали этот namespace контекстом, не как формальный термин, а как определение сущности, как назвать маленькую посылку на почте "пакетом".


Потому, что его поведение такое. Если представить, что крутимся в некотором самом внешнем run(), что измениться? Можно кодом?


Интересный момент, похоже var a = 10 проверяет существует ли a в собственных аргументах, если да, присваивает значение. Спасибо за пример, есть ли ещё?


Попробуй описать своими словами, мне похоже не очевидно.


Устал объяснять, передача объекта в функцию как this - есть вызов в контексте объекта. Перечитывать до просветления. Думаю этот вопрос закрыт.



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

Не лучший. Допустим, в отношении js есть несколько концепций по поводу методов:

a) значение this рулит, им (значением this) и определяется владелец/метод и т.д.;
б) значение свойства объекта рулит, если это значение функция, то это и есть метод;
в) методов нет вообще, т.к. нет никакой связи; (Sardar)

ECMA тебя не увлекает, поэтому в потверждение пункта б) , за который я ратую, тупо цитирую Brendan-a Eich-a, создателя всего этого безобразия:




Вот именно, что без указания объекта. Послушай, как звучит - без указания объекта, но в контексте объекта. Интерпретатор сам вместо null (объекта же нет, функция сама по себе) рисует нам window. А была бы эта вложенная функция именованной, объект уже был бы, но т.к. он запрещён к показу (Activation Object), то вместо него интерпретатор рисует null, а потом снова window на выходе. Я бы не назвал такие вызовы вызовами в контексте объекта window, т.к. привязка мегаискусственная, лишь бы було, this для таких случаев вообще не имеет смысла...


Так и есть.




  

Так б и в одинаковы, "тупо цитирую Brendan-a Eich-a" - говорим же об одном и и том же - метод - лишь поле (slot) значением которого является функция (и это я говорил на протяжении всего топа ;-) ).

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


А представь что нет функций "самих по себе". Все функции как значение равнозначны и не имеют привязки к объектам, this задаётся программистом на момент вызова. Обьявляя функцию мы создаём переменную (реально переменную, можешь присвоить ей любое значение после), содержащую нашу функцию. Попробуй теперь дать своё определение "функция сама по себе" (нюансы синтаксиса оставь в стороне, ищи разницу в поведении).


Поясни кодом, не пойму хода мысли. Также поясни чем отличается именованная функция от анонимной (да, имя функция конечно сохраняет, но особого смысла не несёт, из кода кроме как регами вырвать из .toString() нельзя).


Твой пример с closure vs. function есть лишь догадка   Оптимизатор может отследить все ссылки и выяснить, что функции контекст не нужен, тогда возможно представить функцию более лёгким объектом. Но может и не сделать, теория позволяет и то и другое, все функции closures, даже если не используют контекст (жаль конечно сборщик мусора в этом случае...  ).

С интересом слежу за беседой  



Одной из отличий - "декларация" имеет приоритет перед var (в variable object функция затирает var, если слот с таким именем уже был, в общем - функции занимают места раньше, а затем var'ы):








P.S. Если я где-то сказал не по ECMA Specification, прошу не кидаться помидорами  

Ну, если считать что "в js методов нет" и "в js методы есть" - это одно и то же по смыслу, тогда одинаковы.   


Метод от неметода отличает то, что метод - это свойство, только не простое, а callable. Такая вот простая незатейливая концепция. И this и привязка тут не при чём. Все методы - это свойства, но не все свойства - методы.


Функции (function-value) не имеют, а свойства имеют. У свойства есть владелец, но при вызове анонимной функции она сама по себе, честного this у неё нет, т.к. она весчь бесхозная, материализуется "нечестный" совершенно ненужный this в виде window. Функция вызывается вне всякого контекста (имени нет), this руками не указывается, а навязывается чужеродный э... до кучи.


Зачем тут код-то. Вложенная именованная функция является чьим-то методом. Чьим? Методом Activation Object (AO) той функции, в которой она определена. При вызове этой вложенной функции значением this должен быть AO, но в js это запрещено, и this заменяется на AO->null->window. Это тот случай, когда метод вызван вроде бы в контексте своего непосредственного владельца (caller-a), но его нагло отсекают на подлёте, и в this попадает другой объект.


Ничем, кроме того, что именованная функция - это как бы слот: значение, а анонимная - это значение.


Разгадка. Свободных идентификаторов в первом случае нет, всё на этом, функция самодостаточна, замыкания нет.


p.s. вот прошлогодняя тема с похожими тёрками, тоже конец февраля, обострение что ли...


Это сообщение отредактировал(а) Zeroglif - 1.3.2008, 02:13

Почти, декларации функций как и var сразу создают переменную, просто var заполняет её значением undefined, пока интерпретатор не дойдёт до места ссылка = ...
Кстати, именно поэтому не важно где стоит var (конечно только не в теле вложенной функции), если хоть раз встретилось такое объявление - переменная будет видна по всему локальному контексту.

Если давать определение методу как просто callable в поле объекта, то ты прав. Считаю что это не корректное определение метода, метод - эксклюзиная операция связанная с объектом или группой однотипных объектов. Эксклюзивная - подразумевает мне не нужно знать кому принадлежит метод, его можно вызвать и объект владелец будет верно найден "сам по себе" и подставлен в this. Если мне нужно указывать на каком объекте вызвать метод и метод вообще можно вызвать на любом объекте без ограничений, то это не метод, а callable, которую можно "применить" на чём угодно. Почему такое определение - потому что оно несёт пользу. Если нет пользы от знания, что есть "просто функции" и "методы", то концепция лишняя. Читать до просветления.

На встречу, путаешь понятия значения и ссылки. callable - значение. object.method - ссылка, которая может содержать callable. 
Последующие возражения принимаю только в виде:

Всё остальное буду считать флудом. Мне ещё никогда не удавалось столько раз повторится и оправдаться за день. Устал и надоело.


На callable может ссылаться ссылка object.method, о каком понятии "владение" идёт речь? А если таких ссылок масса, из переменных, массивов, свойств других объектов, включая обработчики событий нативных объектов - и всё это на один и тот же callable объект?


Нет, интерпретатор не смотрит "принадлежит" ли кому либо функция. Он просто смотрит вызвали ли её на ком либо. Если это null, то заменяет его на дефолтный global. Впрочем говорим о результате одного и того же механизма, взгляд под разными углами.


Не совсем, вложенная функция не является методом AO (если под AO ты считаешь локальный контекст == контекст вызова == набор всех локальных перемнных == map сущность, создаваемая при вызове функции == ...). Создаётся пара (имя => callable), которая добавляется в локальный контекст. При вызове имя() интерпретатор знает ещё до начала поиска пары (имя => callable), что объекта для this ты не передал, что нужно поставить global. Вызвать callable в контексте AO (т.е. сделать AO == this) по моему не реально, тогда все переменные объявленные var name (пары name=>value в AO) будут видны как this.name -- такого фокуса ещё не видел (ну разве что в Forty - простой Forth подобный язык, реализованный мной для микроконтроллеров, часть большого неоконченного проекта  ).


Почти, просто именованная функция создаст дополнительную ссылку с именем, которую нельзя удалить через delete, но запросто можно переписать чем угодно. Хотя в принципе этого тонкого различия достаточно, что бы подтвердить твоё наблюдение.


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

Наконец-то. Разглядел и признал-таки определение из стандарта языка. Всего год прошёл.


Мы обсуждаем вызов анонимной функции при отсутствии каких-либо идентификаторов, когда в this подставляется от балды объект window по той причине, что вызывающего объекта просто нет, какая ещё масса ссылок:




Я говорил о принадлежности метода/свойства. В целях определения this интерпретатор смотрит, стоит ли слева Reference type, если да, то кто есть владелец свойства (base object), он и должен стать значением this. Точно такое же выяснение владельца свойства или принадлежности свойства происходит при других операциях (typeof, delete и т.д.), вызов роли не играет.


Создаётся свойство объекта Activation Object (AO) с именем, соответствующим имени функции, а сама функция становится значением этого свойства. Вот тебе и метод. "Читай до просветления" ES 10.1.3.   


Глупости, в js первоначально вычисляется идентификатор в тип Reference, только потом на его основе определяется base object, который потенциально должен стать значением this. Это означает, что интерпретатор ничего не знает про this до того, как разберётся с идентификатором, то есть поиск в scope chain первоначален.


Не постил бы каши из головы, не пришлось бы оправдываться. У тебя там четыре контекста сейчас вместо одного...  

Что именно? Бесполезным оказался пример "Унаследованный контекст - по сути НЕ ТОЛЬКО ЛИШЬ локальный контекст "родительской" функции"?


Минуточку! Я согласен играть по вашему правилу:

, а Вы?


Кому-то по барабану, а мне нет. Отсюда и топик.


На самом деле в ES3 нет ни namespace, ни namespace, переименованного в context – есть Scope. 


Да где же такое же? Написал ведь, что нет arguments object'а, нет формальных параметров. Могу добавить, что и variable object'а тоже нет (вместо него – global object). К тому же this value – это тоже global object. В какой функции это возможно? Вы ведь сами-то за что стоите? За то, что this не должен указывать на variable object (Sardar: "Вызвать callable в контексте AO (т.е. сделать AO == this) по моему не реально"). А в global scope  пожалуйста: this.Number, Number, (местами window.Number) - это запросто. Да и сама эта ваша run() когда заканчивает выполнение? Когда движок построчно пробежит до конца файла js? Или когда? И что она возвращает и куда?


На каждую отвлеченную фантазию выдать код? Я не справлюсь.


Пока нет.


Я очень надеюсь, что уважаемый Zeroglif сделал все (и даже больше), чтобы Вы сумели увидеть разницу. На всякий случай добавлю цитату R. Cornford'а (имея дело с js Вы обязательно должны знать, кто это, и уважать его мнение):

Надеюсь понятно, что "грести все под одну гребенку" – это не верно?


Не передается объект в функцию, как this. Передается значение. 
Мне кажется, что Вы сами запутались в этих контекстах. Вы возражали Zeroglif'у (спасибо ему за ссылку на прошлогоднее "обострение"):

В результате получается, что есть контекст функции, и есть таже функция в контексте объекта. В результате - контекст в контексте.  И к чему тогда имеет отношение this? К "контексту объекта", к execution context'у, в котором вызывается функция (т.е. calling context), или к  execution context'у выполнения самой функции?. Или к чему-то еще?
Рановато закрывать этот вопрос.


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


Да нет, не думаю. Скорее неожиданность, так ведь?


Да какие там магия и исключение? 
Ваша беда в том, что Вы пытаетесь все унифицировать. Определение метода, предложенное Zeroglif'ом, Вам кажется некорректным. А все потому, что Вам, как ни странно, в голову не приходит то, что в информатике, также как и в любой другой области деятельности человека, могут существовать отличные друг от друга контексты. В результате может быть несколько разных трактовок одного и того же термина. 
Как результат заблуждений - уверенность в том, что именно ваш термин является единственно правильным вне зависимости от контекста ES.

И тем не менее это концепция. Можно считать  что методов нет, ничего не изменится. Это не одно и тоже, как если считать, что методов нет в Java. Стандарт просто назвал эту конструкцию методом, удобней для восприятия. Любой другой стандарт может назвать  "методом"  всё что угодно и это будет верно в рамках стандарта. А если отталкиваться от общепринятого (ну в рамках моего опыта хотя бы  ) понятия метода, то:

• метод - операция эксклюзивно связанная с набором данных, метод пишется для работы с этим данными и не может быть применён к любому объекту (кстати, можно расширить идею до traits из Fortress, но опять же метод из trait работает только с данными, определёнными этим trait)
• функция - общая операция, возможно выдвигающая контракт по своим аргументам (не всё можно подставить), но применить такую функцию можно к любому объекту/данным. Нет логической привязки к данным.

Переубеждать не буду, пока формально не определить  что есть  "метод", спор не будет иметь  смысла. Как человек пишущий на Java/C/Haskell тоже, для меня определение из ECMA теряет силу вне контекста JS.


Идентификаторов чего, функции или объекта, чей "метод" вызываем? Если первое, то как имя функции используется при вызове, кроме как найти callable (дополнительная процедура перед самим вызовом)? Если второе, то:


Быть может опять называем одни и те же вещи разными именами? Быть может снова используешь "подогнанное под JS"  понятие из ECMA (если да, то цитируй)?


Согласен, что ты сам (ты программист JS) задал на ком вызвать "метод"? object.method() - эквивалентен {callable}.apply(object, ...), в самом методе ты не сможешь узнать как тебя вызвали, какое имя "метода" было у объекта и т.п. Это ведь сильно отличается от вызова метода к примеру в Python ;-)   Мы говорим о механизме вызова, а не о его синтаксической составляющей. Впрочем расширение синтаксиса имеет место быть, () - не просто оператор вызова callable, парсер смотрит как было обращение к callable, отсюда:

• object.method() - парсер выделяет кортеж (object, object.method, ())
• (object.method)() - парсер выделяет кортеж (global, object.method, ())

При этом object.method может не существовать, ещё до начала выполнения известно, кем будет this (читай или global, или объект по ссылке object).


Если считать  АО объектом. Только эта вещь не доступна доступна как объект в JS коде, это сущность реализации, а в реализозвать  его можно как угодно. Понятия "метод объекта AO" отсюда теряет смысл. ECMA задаёт подобный термин для формального определения поведения, а есть ли упоминание AO как сущности доступной в JS коде? ;-)


И ты туда же? Захочешь это повторить, пиши в PM.


И чем это противоречит сказанному мной? На лицо "нет! нет!! нет!!!" без попытки уяснить смысл моих слов?


А... объект это не значение?  Боже, похоже нужен многостраничный список терминов, что бы мы начали понимать  друг друга... Может приведёшь тогда цитату из ECMA в подтверждение правильного значения "объект" и "значение" (не надо падать  до "объект" это частный случай "значения", давай обсудим именно твою цитату).



Это бессмысленный спор, я "перевёл" все свои термины на используемые тобой, твоё не желание трезво прочесть мои слова скатывается до рандомных мыслей. Понятия "контекст функции" (его же называл локальным контекстом, контекст вызова и т.д., в ECMA АО) и "контекст объекта" (собственно все поля объекта) совершенно ортогональны друг к другу, понятие "контекст в контексте" ты придумал сам.


Вовсе нет, нативные методы - грязных хак. Я могу создать нативный метод, что будет существовать у всех объектов (даже на null кидать исключения не будет), но у Object его не будет. Я могу реализовать метод Array, что будет выдавать кусок памяти по рандомному адресу. Я могу делать  всё что угодно вне концепции языка. Если это не понятно, то дальше продолжать  не стоит.


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


Ого!     По моему это вы категорически отвергаете мои термины, не вникая в суть. По моему это от вы опираетесь на copy-paste термины из ECMA, отвергая синонимы, будто процессоры символьных вычислений. По моему это я на протяжении всего топа искал аналогии своих формулировок с формулировками из ECMA, доказывая эквивалентность по смыслу, а не по букве 


Парни, чую вы напряглись. Если кто-то имеет сомнения в моей компетенции, в моих знаниях в области JS, то создай тему, в которой выложи свои формулировки и приведи кардинальные отличия от моих. Будь готов к тому, что другие люди будут всё таки сравнивать смысл, а не слово. Если у меня зародятся хотя бы сомнения в моей правоте, то я покину пост модератора, т.к. не достоин вести этот раздел не имея совершенно базовых знаний в JS.

А то в этом топе как в классической поговорке, "один человек может привести лошадь к водопою, но даже сотня не заставит её пить" -- мне чую не удастся помочь вам взглянуть на смысл моих слов, пусть и изложенный не терминами ECMA.

Ха, какой грязный способ закончить дискуссию   

Сказанное Вами: "...все функции closures, даже если не используют контекст". Неужели самостоятельно не удается найти отличия от формулировок Zeroglif'а и Cornford'а?


Цитата из ECMA:

Есть разница? Или опять, как всегда, нет?


Не придумал, а констатировал то, что следует из ваших заявлений. 


Может быть не стоит?


Действительно, зачем вообще надо было писать о вещах трансцендентного свойства?


То-то и оно, ведь действительно верно.


Видите к чему приводит раскованность? Вас сложно понять. 
Если речь об ES – пусть она идет в соответствующем контексте. 


Да, а то как же? Что мне, пытаться, к примеру, Delphi проецировать на ES? Это же глупо. 


А где тут однозначность или схожесть по смыслу?


Так ведь не удается (от а до я).


Что, этой темы мало?


Знаний-то достаточно. Или Вам показалось, что Вас кто-то подсиживает? 

Sardar,

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


Согласен?


test - это не только имя для lookup-а, наличие имени уже говорит о том, что это Reference type, то есть кроме того, что будет произведён поиск идентификатора (возможно с участием прототипа), для определения значения this будет вычислен base object (владелец свойства). Мы не указываем владельца руками, но владелец в случае с именами реально есть (имена - это свойства какого-либо объекта), владелец будет найден и подставлен в this. Во втором же случае он не будет найден вовсе, но будет подставлен. В первом случае вызов в контексте глобального объекта, во втором вне контекста какого-либо объекта, но без this в js остаться нельзя, принудительно от балды подставляется глобальный объект.


Неправильно мыслишь, во втором случае не должно быть global в последовательности, т.к. в js оператор группировки (скобки) может возвращать Reference type, говоря простыми словами, он что есть, что его нет, вызов во втором случае ничем не отличается от первого.



AO назван объектом, у него есть свойства, значением свойства может быть функция. Всё в рамках ES, именно метод. Получить доступ к AO невозможно (я могу ошибаться, но мне кажется это можно сделать во Flash). Что касается сущности доступной в коде, то я тебе приведу другой пример, попробуй его разгадать:



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

Добавлено @ 17:13
AKS, замыкания в js вещь спорная, можно считать, что все функции замыкания, можно считать иначе, вплоть до того, что их нет вообще. Формального определения нема, каждый ратует за свою концепцию. По-моему я это уже здесь писал как-то, на мой взгляд считать все функции подряд замыканием просто не вкусно, нет акцента, более идейно, когда замыкание характеризуются 2-мя признаками:
 
1) функция пережила контекст исполнения, в котором она была создана;
2) функция имеет на борту "свободные" переменные;

Под "переменными" подразумевается понятно что. В этом случае замыкание взведено и готово к работе.   

Это сообщение отредактировал(а) Zeroglif - 17.3.2008, 16:26

Наверно не такая уж спорная. Но, как бы то ни было, мне понятно ваше определение, и никакое другое (видел всякое уже).
У меня же к Sardar’у немного другие вопросы. Он cначала писал: "ECMA разделяет декларации функций и функции-closure как значения". Тут сразу возник вопрос – если выделен термин FunctionDeclaration, то он не может ассоциироваться с closure? Или все-таки может? А во втором случае вопрос немного иной – если созадется FunctionExpression, обязательно будет формироваться closure? Или нет? Затем Sardar уже заявил, что "все функции closures, даже если не используют контекст". 
Думаю, что надо избавляться от непоследовательности и двусмысленности. Пусть определится и все.

Кстати, что с вызовом функции в контексте объекта? Как быть? Sardar’у уже устал, а я не могу нигде ничего подобного найти в контексте ES. Давайте уж Вы, что ли, такое же определение, как и с closure.

Давайте будем материалистами ;-) Материалисты познают мир методом научного тыка. Если методом научного тыка не удается увидеть разницы между closures и обычной функцией, то нечего и огород ородить, поминая библию (ES документацию) и высказывания апостолов ...   

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

Только в этом разделе и только говоря о JS - да 


Проверил, действительно так. Года 3 назад писал интерпретатор JS на Java, вот тут бы моя реализация тест бы и не прошла   

Вывод: (object.method) - действительно отдаёт не просто callable, а кортеж (object, callable) (ECMA Reference type?), достаточно что бы верно вызвать функцию как метод. Похоже переменная не может содержать такой тип, поэтому присвоение выберет только callable.


Вообще это хорошо, т.к. иначе можно было присвоить совершенно чужой метод левому объекту, тогда obj.method могло выдать (object1, (object2, callable)). Тут у интерпретатора три пути, либо кинуть ошибку, мол ожидалось callable; либо отбросить object2 (поведение идентичное нынешнему), либо отбросить object1 (что совсем не верно, вызов метода на одном объекте возбудит вызов метода на совершенно левом объекте).


*****! браво 
Жаль пример только для мозиллы, ни Опера, ни ИЕ не будут искать m в прототипе объекта. Интересно, задано ли это поведение в ECMA или свободная интерпретация мозилловцев...  В любом случае действительно в мозилле найдём и запустим m(), да на this == AO, содержащим функцию f как поле .f (метод). Теперь буду думать как это эффективно реализовать, а то млин ссылок много)


По идее первого условия уже достаточно.

Добавлено @ 19:04

Жутко удобно в разного рода итераторах. Посмотри как в Ruby к примеру в базу запрос сделать и пробежаться по всем строкам. Кратко, локально, элегантно.

Пара вопросов по замыканиям:



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




можно пояснить второй пункт? я не понял, кто такие "свободные" переменные =)




если под FunctionDeclaration подразумевается function f() {...}, то почему нет?




  


Это сообщение отредактировал(а) dsCode - 1.3.2008, 19:09

Это тоже самое, что у Zeroglif'а, только из уст "материалиста".


Так вот там и нет, как назло, ничего об этом.





Вот и все.


Задано. Только Вы не разгадали. Объяснения – за Zeroglif'ом, как за автором. А я предложу вообще чисто мозилловский вариант на ту же самую тему – может поможет разгадать загадку Zeroglif'а (интересно, а он на меня не разозлится, что я подсказываю  ):





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


Вопрос нужно читать в контексте заявления о делении на FunctionDeclaration и функции-closure.


Это, кстати, не FunctionDeclaration (разве что в IE)...

Это сообщение отредактировал(а) AKS - 1.3.2008, 19:44

Не совсем мне понятен вопрос, в каждой функции "живёт" чужая сохранённая scope chain того контекста исполнения, в котором функция была создана. Живёт и ждёт вызова функции. В момент вызова чужая scope chain объединяется с объектом активации вызванной функции, так из двух частей формируется уже её собственная scope chain, которую тоже может запомнить какая-нибудь другая вложенная уже в эту функцию функция.


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


Тут обсуждалось.


Это почти честное поведение согласно ES, только мне немного непонятна очередность объектов в scope chain в данном случае (надо снова разбираться). Тот объект, что в примере - это не AO, а спецобъект отдельно для хранения имени функции, которое может быть доступно только изнутри. Рррр... Как же надоели уже причуды с именованными вложенными FunctionExpressions...


Надо подумать. По идее фразу "вызов в контексте бла-бла-бла" можно читать, как "вызов, при котором значением this является бла-бла-бла". При этом само собой просится, чтобы значение this никак не менялось в дороге. Отсюда я категорически не воспринимаю подстановку вместо реальных объектов, это ломает всю картину. С одной стороны получается, что энная функция вызвана в контексте глобального объекта, а с другой стороны это такие странности реализации, this такому вызову и не нужен вовсе. Раньше я считал, что нужен, сейчас понимаю, что был бы тот же null, хуже не стало бы, может даже и лучше.

Это сообщение отредактировал(а) Zeroglif - 1.3.2008, 20:31

Zeroglif, спасибо =) Т.е. scope chain "дочерней" функции в любом случае будет будет расширен полным scope chain'ом "родительской", если родительская возвращает дочернюю. Я имею в виду, если в замыкании используется лишь одна (свободная, не привязанная для замыкания) переменная из тысячи родительских var'ов, скоп чейн "дочерней" помимо своих var'ов будет содержать всю тысячу родительских, да?



искать, пусть, не будет, а скоп чейн ее будет расширен родительской функцией?

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

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

Без всяких "если". Вернут не вернут не важно. Это происходит в момент создания функции, а что с ней дальше будет происходить не играет никакой роли.


Без всяких "если". Наличие/отсутствие переменных также не играет никакой роли. Функция помнит не var-ы, а объекты (Variable Objects), из которых состоит scope chain.


Да. Только не функцией, а scope chain.

Добавлено через 9 минут и 27 секунд

В принципе так и есть. Контекст - это чей-то мир, а this - ключ в этот мир.

Sardar, Zeroglif, ага, спасибо =)

Если не секрет, был ли кто-либо из тех, на кого обычно ссылаетесь (Brendan, Richard etc), замечен Вами в употреблении чего-нибудь, вроде: "call the function in the context of some object" (это мне для расширения кругозора, если позволите)?

AKS, высаживаешь  Честно говоря пока не дочитал до последней фразы... думал что все кончится вот так:




тяжелых наркотиков   

Хех, моя шпионская сеть не раскинулась так широко. AKS, чего за червяк вас гложет-то, если вы посмотрите на родные доки JavaScript (начиная с 1.3), то в отношении тех же apply и call вся эта терминология применяется легко и непринуждённо:


что в переводе на более-менее формальный язык ES банально расшифровывается прямо там же, как:


Отсюда вы можете легко додумать, что, говоря о рядовом вызове функции/метода можно применить ту же самую терминологию, там ведь тоже есть this, только он не different, как при apply/call, вся разница. В общем, каждый транслирует ES по-своему, главное, чтобы эта трансляция не рушила идею, на мой взгляд "в контексте объекта" эту идею не рушит в отличие от вышеописанных здесь "наследуемого контекста" и "локального контекста", которые идею не передают. Лично я в голове в отношении this вообще использую конструкцию "передача в функцию скрытого аргумента", мне так удобнее...   

Да каких там тяжелых. Те, о ком речь, и легкими видимо не балуются. Излагают внятно-понятно, а значит и мысль ясна и девственно чиста, и никакого тумана...



Жаль. 


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


Да смотрел, даже уже здесь кое-что цитировал на первой странице:

Только Вы ведь меня научили не доверять этим мозиловским вики-архивариусам. Помните дело с конструктором Function? После еще читал, как Brendan Eich делал замечания по поводу контента на MDC.