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


А чем аргументы отличаются от точно таких же локальных переменных, объявленных 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? Это же глупо. 


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


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


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


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