Размышления о замыканиях

[Ostic]

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

[scrollquest]

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

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

[Ostic]

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

лукап это же массив??
а это ~x или O(x)... чего-то я сомневаюсь очень, а если это игра?
с линейной сложностью поиска, например? так еще и память, не факт, что непрерывным куском выделяется? так еще и сборщик мусора, который будет дыры в массиве оставлять?(для хэш-таблиц дыры только упростят все)

добавил я свойство

function.attribute = 1;

по-вашему, атрибут добавляется в конец массива и когда мне следующей командой надо к нему обратиться, то я должен пройти весь массив, а если кол-во обращений 1000, а количество атрибутов 100?
сложность 10x^2
что-то я сильно сомневаюсь...
не быстрее ли двинуть битовой операцией имя и получить таким образом индекс массива, где хранится атрибут? сложность - полтакта, условно говоря. и вставка такая же.

[scrollquest]

лукап это же массив??

Нет, лукап -- это функция, которая производит поиск, в данном случае переменных

[warren buffet]

они укладываются в дерево корень

Какое дерево? Жабаскрипт - интерпретатор. Текст у тебя, а не дерево. Доходит до текста - компилит все что "видно", уходит из текста - забывает. Чтобы не забывало переменные должны быть в том тексте, до которого look - доходит всегда - up. Из-за чего были придуманы такие чудесные обходы как .bind()

Почему кложа - замыкание я метафоры тоже не понял. Кложа - затычка, чопик.

[warren buffet]

Прочитал несколько небольших статей про замыкания
...
"копал" исходные коды?

Все с тобой ясно, целкодрочер. )))

[moron]

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

function carryAdd(a, b){
  //анонимная функция при своем создании
  //знает значение a и замыкает его.
  //поэтому переменная a доступна внутри :c
  return function(b){
    return a+b
  }
}
foo = carryAdd(5);
foo(10)// 15
foo(5)//10

С помощью замыканий можно реализовать инкапсулирование переменных. Т.е когда переменная находится внутри обьекта, а доступ и изменение осуществляется с помощью геттеров\сеттеров

[Ostic]

Нет, лукап -- это функция, которая производит поиск, в данном случае переменных

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

надо смотреть что там за структуры() и тогда понятно станет как замыкания понимать. причем разные (у js же есть даже jit-compilier).
вы думаете там нет таблиц посика? Нет...
потом новые Map, Set...

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

Какое дерево? Жабаскрипт - интерпретатор. Текст у тебя, а не дерево. Доходит до текста - компилит все что "видно", уходит из текста - забывает. Чтобы не забывало переменные должны быть в том тексте, до которого look - доходит всегда - up. Из-за чего были придуманы такие чудесные обходы как .bind()
а объекты как организованы, как организован поиск? я видимо в других категориях мыслю - я не знаю лукап (это какая-нибудь фирма придумала, для внутреннего пользования или это какой-то хоть страны или фирмы стандарт?)

чего, вы как-то пренебрижительно отнеслись ИМХО
нифига себе javascript интерпретатор или компилятор!?

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

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

[Ostic]

вы посмотрите, как даже DOM организован - "дерево" - модель в виде дерева )), а то , что вам так его в отладчике показывают не факт что именно так все - это просто вьюха.

[Ostic]

когда имя в адрес декодируется (с низкой ценой).
деревья легко сливать и добавлять, и искать, и вставлять.
крикнул "э,Вася" и вот тебе "Вася". + Порядок можно задать на дереве, поэтому я предположил, что функции храняться в виде дерева, а глобальный контекст хранить в таблице поиска - она же "хэш-таблица'), ведь не надо "глобальный контекст" сливать же - правильно?
А вот поиск, вставка (если только), то лучше общая объектовая таблица,собственно, имя декодируется в адрес, как было сказано выше.
тогда понятно почему так: все глобальные имена в таблице, с которой все модули работают как с БД.
Понятно что "раскладушка" получается и иерархия - идя по дереву вверх мы попадем ,в конце концов в глобальный контекст - объект window,притом за "гарантированное время".
тогда, для меня понятна концепция замыканий и областей видимости.