Полезные статьи

Заявлением по форме 262-3 образец

Оглавление:

Форма С-09-3-2 (образец прилагается)

Обновление: 21 сентября 2016 г.

Отечественное законодательство допускает открытие российскими юридическими лицами обособленных подразделений, то есть филиалов, представительств и иных. Процедура их открытия и требования, предъявляемые к ним, детально описаны в соответствующих законотворческих актах. Открытие и закрытие некоторых подразделений носит уведомительный характер. Для закрытия представительства необходимо направить в налоговый орган заявление по форме С-09-3-2 .

Общие положения об обособленных подразделениях

Гражданский кодекс Российской Федерации (в редакции, действующей на текущий момент) допускает создание и существование юридических лиц, которые, наряду с другими субъектами хозяйственной деятельности, в той или иной степени участвуют в предпринимательской деятельности или создаются для достижения конкретных целей (ст. 48 ГК РФ).

Указанные лица вправе открывать обособленные подразделения.

Согласно ст. 11 НК РФ обособленное подразделение должно находиться по адресу, отличному от адреса головной организации, и иметь стационарные рабочие места, т. е. рабочие места, созданные на срок более одного месяца. Обособленным подразделением является не только филиал или представительство, но и отдельное рабочее стационарное место (ст. 55 ГК РФ и ст. 11 НК РФ ).

Уведомление налоговой инспекции о создании обособленных подразделений происходит путем заполнения соответствующих форм заявлений. Федеральная налоговая служба России издала приказ от 09.06.2011 № ММВ-7-6/362@ , которым утвердила формы заявлений для открытия обособленных представительств и их закрытия.

Заполнение формы заявления о закрытии обособленного подразделения

Скачать форму С-09-3-2, используемую при закрытии обособленных подразделений, можно на сайте ФНС РФ www.nalog.ru или же найти с использованием СПС «Консультант+». Скачивание формы с использованием других источников не гарантирует ее соответствие утвержденному бланку.

Требования и порядок заполнения вышеуказанной формы подробно описаны в приложении № 14 к указанному приказу.

После того как бланк формы С-09-3-2 скачан, можно переходить к его заполнению.

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

Если же форма распечатывается на принтере, то ее заполнение выполняется шрифтом Courier New высотой 16 — 18 пунктов.

Важно помнить, что поля, предназначенные в форме для указания ИНН и КПП, должны быть заполнены на каждой странице заявления. Детальные требования к каждой графе, подлежащей заполнению, изложены в приложении № 14 к Приказу ФНС России.

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

Нумерация заявления является сквозной, все листы нумеруются нарастающим итогом.

Федеральная налоговая служба России утвердила указанную форму заявления в вышепоименованном приказе. Также ФНС России разработала и ввела в действие общий порядок заполнения формы заявления и предусмотрела основные и обязательные требования к такому заявлению, но образец заполнения формы С-09-3-2 не разработала и не разместила.

Образец указанного заявления можно скачать по ссылке.

glavkniga.ru

You are here

Форма N 26.2-3. Уведомление об отказе от применения упрощенной системы налогообложения

Все налогоплательщики, которые применяют УСН, имеют право добровольно перейти на иную систему налогообложения. Для этого они должны подать в налоговую службу по месту их регистрации соответствующее уведомление. Форма такого уведомления об отказе от применения упрощенной системы налогообложения утверждена ФНС N26.2-3. Уведомление подается с начала года, не позднее 15 января. Заполнить бланк можно вручную либо машиночитаемым способом. Предоставляется лично заявителем или отправляется средствами почтовой связи с уведомлением о вручении.

Бланк формы состоит из одного листа формата А-4. При его заполнении необходимо указать индивидуальный номер предпринимателя или код ОКПО предприятия и код налоговой организации. Далее следует полное название фирмы или фамилия, имя и отчество (при наличии). Следует написать год, с которого субъект отказывается применять УСН.

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

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

blanker.ru

ЕНВД-3. Заявление о снятии с учёта организации как плательщика ЕНВД

В то время как форма ЕНВД-1 служит для постановки предприятия на учет с налогообложением по вмененному доходу, ЕНВД-3 применяется для прекращения действия этого регламента.

Образец заполнения и пустой бланк формы ЕНВД-3

Использование формы

Таким заявлением организация подтверждает свое намерение отказаться от ЕНВД. Причин может быть несколько, включая невозможность вести деятельность в спецрежиме (например, количество сотрудников превысило 100 человек) или переход на другой вариант налогообложения. Эти причины нужно будет указать согласно коду, приведенному в шапке.

Выход организации из режима ЕНВД осуществляется по заявлению. Форму следует подавать и в том случае, когда компания временно не ведет деятельность, так как исчезает причина для налогообложения по спецрежиму.

Особенности заполнения

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

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

Если форму подает не руководитель компании, а представитель, на него нужно заполнять соответствующие поля. В графе “Документ” предусмотрено только название — устав, доверенность и т.п. В случаях, когда у ответственного лица отсутствует отчество, эту строку оставляют пустой. У нас форма ЕНВД-3 подаётся доверенным лицом.

КПП должен соответствовать тому, что вы указали в ЕНВД-1. Если вы закрываете предприятие или переходите на другую налоговую ставку, количество видов деятельности может увеличиться. Для этого распечатайте 2 экземпляра приложения и внесите следующие (после третьей) услуги в ячейки на второй странице. Соответственно, поменяется и число страниц в документе, что отражено на титульной странице. У нас — 2 кода вида предпринимательской деятельности, и хватило одного листка приложения:

Сроки и особенности подачи

Как и другие формы этого типа, ЕНВД-3 нужно подавать в пятидневный срок. Он высчитывается от даты прекращения деятельности. Исключение — случаи, когда предприятие перестало соответствовать требованиям по “вмененке”. В этом случае нужно подавать в последний день месяца в текущем налоговом периоде.

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

Когда форма ЕНВД-3 не нужна

Не следует забывать, что это заявление рассчитано на организации. Соответственно, оно не подойдет для ИП. Таким предпринимателям нужно подавать форму ЕНВД-4.

assistentus.ru

Dmitry Soshnikov

Software engineer interested in learning and education. Sometimes blog on topics of programming languages theory, compilers, and ECMAScript.

Dmitry Soshnikov in ECMAScript | 2009-07-07

Тонкости ECMA-262-3. Часть 5. Функции.

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

от функций, определённых в “привычном” виде”?:

Или, “почему при следующем вызове, функцию обязательно нужно оборачивать в скобки?”:

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

Но, давайте по порядку. Начнём мы с рассмотрения видов функций.

Виды функций

Всего в ECMAScript существует три вида функций, и каждый из них обладает своими особенностями.

Декларация функции (Function Declaration)

Декларация функции (Function Declaration, сокращённо FD) — это функция,

  • обязательно имеющая имя;
  • находящаяся в коде непосредственно: либо на уровне Программа (Program), либо внутри другой функции (FunctionBody);
  • создаваемая на этапе входа в контекст;
  • воздействующая на объект переменных;
  • и объявленная в виде:
  • Основная особенность функций данного типа заключается в том, что только они воздействуют на объект переменных (т.е. попадают в VO контекста). Данное свойство определяет их вторую особенность (вытекающую из определения VO) – к моменту этапа интерпретации кода контекста, они уже доступны (т.к. попадают в VO ещё в при входе в контекст).

    Пример (функция вызывается раньше, чем объявлена):

    Также важным моментом является второй пункт из определения – местоположение декларации функции в коде:

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

    Альтернативой (и, даже можно сказать, противоположностью) декларациям функций, являются функции-выражения.

    Функция-выражение (Function Expression)

    Функция-выражение (Function Expression, сокращённо FE) — это функция,

    • всегда находящаяся в зоне выражения;
    • имеющая опциональное имя;
    • не воздействующая на объект переменных;
    • и создаваемая на этапе интерпретации кода контекста.

    Зоной выражения обозначим любую часть программы, распознаваемую как выражение ECMAScript. Простейшим примером выражения, является выражение присваивания:

    В данном случае представлена анонимная FE, которая присваивается переменной “foo”. Далее, функция доступна для вызова посредством переменной “foo” – foo().

    Также, как было отмечено в пунктах определения, FE может иметь и опциональное имя:

    Стоит отметить, что в данном частном случае, снаружи FE доступна всё так же посредством переменной “foo” – foo(), в то время как внутри функции (например, при рекурсивном вызове), возможно использование имени функции “_foo”.

    При наличии имени, FE может быть сложно отличима от FD, однако, зная определение, это отличие становится явным и простым: FE всегда находится в зоне выражения. Ниже представлены различные выражения ECMAScript, где связанные с ними функции являются FE:

    Также в определении сказано, что FE создаются на этапе исполнения кода контекста и не попадают в объект переменных. Покажем данное поведение на примере:

    Спрашивается, зачем они тогда вообще нужны? Ответ очевиден — чтобы использовать их в выражениях и не “загрязнять” объект переменных. Самый простой пример — передача функции в качестве параметра другой функции:

    В том случае, когда FE сохраняется ссылкой в переменную, она остаётся в памяти и доступна посредством этой переменной, поскольку переменные, как мы знаем, воздействуют на VO:

    Другим примером может является создание обособленной области видимости для скрытия от внешнего контекста вспомогательных данных (в примере ниже используется FE, которая запускается сразу же после создания):

    Видим, что функция foo.bar (благодаря свойству [[Scope]]) имеет доступ к внутренней переменной x функции initialize. И одновременно с этим, x недоступна снаружи. Данная стратегия применяется во многих библиотеках для создания “приватных” данных и сокрытия вспомогательных сущностей. Часто в данной конструкции, имя инициализирующей FE опускается:

    Ещё примеры FE, создаваемые по условию и не “загрязняющие” VO:

    Вопрос “о скобках”

    Итак, ответим на вопрос, упоминавшийся в начале статьи — “зачем при вызове функции сразу же после её создания, нужно оборачивать её в скобки?”. Ответ на этот вопрос вытекает из ограничений на инструкцию-выражение.

    Согласно стандарту, инструкция-выражение не может начинаться с открывающей фигурной скобки<, т.к. тогда оно было бы неотличимо от блока, и, также, инструкция-выражение не может начинаться с ключевого слова function, т.к. тогда оно было бы неотличимо от декларации функции. Т.е., если мы опишем вызов функции сразу же после её создания следующим образом (т.е. начиная с ключевого слова function ):

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

    Если мы имеем такое объявление в глобальном коде (т.е. на уровне Программа ), парсер должен распознавать такую функцию как декларацию, т.к. она начинается с ключевого слова function . Поэтому в первом случае мы получаем SyntaxError из-за отсутствия имени функции (функция-декларация всегда должна иметь имя).

    Во втором случае имя задано ( foo ), и по идее, декларация функции должна пройти нормально. Однако, мы всё равно имеем ошибку синтаксиса, но уже, касаемо оператора группировки без выражения внутри. Обратите внимание, в данном случае — это именно оператор группировки, который следует за декларацией функции, а не скобки вызова функции! Т.е., если бы мы имели следующий код:

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

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

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

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

    В примере выше, скобки в конце это уже именно вызов, а не оператор группировки, как было в случае FD.

    Обратите внимание, в примере ниже, при вызове функции после её создания, обрамляющие скобки не требуются, т.к. функция уже находится в позиции выражения и парсеру сразу известно, что перед ним FE, которая будет создана в при интерпретации кода контекста:

    Как видим, foo.bar является строкой, а не функцией, как может показаться при беглом или невнимательном просмотре кода. Функция здесь используется лишь для инициализации этого свойства в зависимости от параметра — она создаётся и тут же вызывается.

    Поэтому, окончательным ответом на вопрос “о скобках”, будет являться следующий: скобки нужны, когда функция находится не в позиции выражения, и мы хотим её вызывать сразу же после создания (в таком случае, мы принудительно преобразуем функцию к FE). В случае же, когда парсеру известно, что перед ним FE, скобки не обязательны.

    Помимо обрамляющих скобок можно использовать любой другой способ преобразования функции к FE, например:

    Однако скобки являются в данном случае наиболее распространенным и элегантным способом.

    Кстати сказать, оператор группировки может обрамлять как описание функции без скобок вызова, так и, включая скобки, т.е. оба выражения, описанные ниже, являются правильными FE:

    Расширение реализаций: Функция-инструкция (Function Statement)

    Ниже представлен пример, который ни одна из реализаций (на текущий момент) не обрабатывает согласно стандарту:

    Здесь стоит сказать, что, согласно стандарту, данная синтаксическая конструкция вообще ошибочна, поскольку, как мы помним, декларация функции (FD) не может находится в блоке кода (здесь if и else содержат блоки кода). Как было сказано, FD может находится только в двух местах: на уровне Программа и в теле другой функции.

    Ошибочна потому, что блок кода может содержать только инструкции (statements). И единственное место, в котором функция может появится в блоке — это одна из таких инструкций — уже рассмотренная выше инструкция-выражение (expression statement). Но она, по определению и, как опять же мы уже отмечали выше, не может начинаться с открывающей фигурной скобки (т.к. неотличимо от блока) и ключевого слова “function” (т.к. неотличимо от FD).

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

    Наличие ветвей if-else подразумевает динамику, выбор, т.е. напрашивается функция-выражение (FE), которая будет создана динамически. Однако большинство реализаций просто создают здесь декларацию функции (FD) ещё на этапе входа в контекст, причём берут последнюю объявленную функцию. Т.е. функция “foo” будет выводить 1, даже несмотря на то, что ветвь else никогда не выполнится.

    Однако, всё же, реализация SpiderMonkey (и TraceMonkey) в этой ситуации поступает двояко: с одной стороны она не считает такие функции декларациями (т.е. функция будет создана по условию, в ран-тайме), но и с другой стороны — это не полноценные функции-выражения, т.к. их нельзя вызвать без обрамляющих скобок (снова ошибка парсера – “неотличимо от FD”) и они попадают в объект переменных.

    Моё мнение, что SpiderMonkey поступает в данном случае правильно, выделяя негласный средний вид функции — (FE + FD). Данные функции правильно будут созданы в нужное время и исходя из условий, а также, в отличие от FE — будут доступны для вызова снаружи. Данное синтаксическое расширение SpiderMonkey называет инструкцией функции (Function Statement, сокращённо FS); эта терминология упоминается на MDC. Создатель JavaScript Brendan Eich также отмечал данный вид функций, присутствующий в реализации SpiderMonkey.

    Особенность именованной Function Expression (NFE)

    В том случае, когда FE имеет имя (named function expression, сокращённо NFE), в силу вступает одна важная особенность. Как нам известно из определения, (и, как мы видели из вышеописанных примеров), функции-выражения не воздействуют на объект переменных контекста (что означает невозможность обратиться к ним по имени ни до, ни после объявления). Однако, FE имеет возможность обращаться к себе по имени при рекурсивном вызове:

    Где же хранится имя “foo”? В объекте переменных самой foo? Нет, т.к. никто не определял никакого имени “foo” внутри foo. В родительском объекте переменных контекста, породившего foo? Тоже нет, т.к. это следует из определения — FE не воздействуют на VO — что мы и видим при вызове за пределами foo. Где же тогда?

    А дело вот в чём. Когда интерпретатор, на стадии исполнения кода контекста, встречает именованную FE, он, перед созданием самой FE, создаёт вспомогательный спецобъект и добавляет его спереди к текущей цепи областей видимости. Далее создаётся сама FE, и в этот момент (как нам известно из статьи о Scope chain) в неё свойством записывается [[Scope]] — цепь областей видимости контекста, породившего функцию (т.е. в [[Scope]] присутствует этот спецобъект). Далее, в спецобъект добавляется одно единственное свойство — имя FE; значением свойства является ссылка на эту FE. И последним действием, спецобъект удаляется из Scope chain порождающего функцию контекста. Отобразить псевдокодом можно так:

    Таким образом, за пределами функции данное имя недоступно (т.к. его нет в Scope), но спецобъект успел записаться в [[Scope]] функции, и там это имя определено.

    Стоит однако отметить, что не всё так гладко в этом моменте с реализациями. Некоторые из них, например, Rhino, записывают это опциональное имя не в спецобъект, а в сам объект активации FE. Реализация же от Microsoft — JScript, полностью нарушая правила FE, вообще сохраняет это имя во внешнем объекте переменных, и оно становится доступно снаружи.

    NFE и SpiderMonkey

    Касательно реализаций, всё в той же SpiderMonkey, есть одна особенность, связанная с этим спецобъектом, которую, в принципе, можно считать багом (хотя реализовано всё согласно стандарту, так что это — больше недочёт спецификации). Связана она с механизмом разрешения имён идентификаторов: последовательный опрос Scope chain является двумерным и при разрешении имени идентификатора, учитывает также и прототипы объектов цепи.

    Наблюдать данный механизм в действии можно, если определить свойство в Object.prototype и обратиться к “несуществующей” переменной из функции, определённой в глобальном контексте. Таким образом, при разрешении имени “x” в примере ниже, мы дойдём до глобального объекта, но и там имя “x” не будет найдено. Однако в SpiderMonkey глобальный объект наследует от Object.prototype и, соответственно, имя “x” будет найдено в нём:

    Объекты активации прототипов не имеют. При тех же начальных условиях, данное поведение можно видеть на примере вложенной функции. Если определить локальную переменную “x” и объявить вложенную функцию (FD или анонимную FE), то при обращении из вложенной функции к внешней переменной “x”, значение её будет найдено из функции выше (т.е. там, где она и находится), а не из Object.prototype:

    Некоторых реализации, являясь исключением, всё же задают прототип объектам активации. Так, например, в реализации Blackberry значение “x” из примера выше будет определено как 10. Т.е. до объекта активации foo мы не дойдём, т.к. значение будет найдено в Object.prototype:

    И абсолютно аналогичную ситуацию можно наблюдать в SpiderMonkey со спецобъектом именованной FE. Данный спецобъект является (по стандарту) обычным объектом — “как если бы new Object()”, и соответственно, должен наследоваться от Object.prototype, что мы и видим в реализации SpiderMonkey. Остальные реализации (включая новый TraceMonkey) не задают прототипа спецобъекту:

    NFE и JScript

    Реализация ECMAScript от Microsoft – JScript, встроенная в Internet Explorer, на текущий момент (вплоть до версии JScript 5.8 – IE8) имеет ряд багов, связанных с именованными функциями-выражениями (NFE). Каждый из этих багов полностью расходится со стандартом ECMA-262-3; некоторые из них чреваты серьёзными ошибками.

    Во-первых, JScript в этом моменте нарушает главную особенность FE – то, что они не должны попадать в объект переменных по имени функции. Опциональное имя FE, которое должно записываться в спецобъект, доступный лишь при активации функции (и нигде более), здесь записывается прямо во внешний объект переменных. Более того, именованная FE трактуется в JScript, как декларация функции (FD), т.е. создаётся при входе в контекст и доступна до объявления:

    В общем, полное нарушение правил.

    Во-вторых, в случае сохранения ссылки на именованную FE в переменную сразу при описании переменной и операции присваивания, JScript создаёт два разных объекта-функции. Данное поведение сложно назвать логичным (особенно, учитывая то, что за пределами самой NFE, её имя вообще не должно быть доступно):

    Вновь – полный беспорядок.

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

    Этот момент объясним. На самом деле, создаётся так же два объекта, но в дальнейшем остаётся, действительно, только один. Если опять учесть, что NFE здесь трактуется, как декларация функции (FD), то ещё на этапе входа в контекст создастся FD bar. Далее уже на этапе интерпретации кода создаётся второй объект — функция-выражение (FE) bar, которая нигде не сохраняется. Соответственно, поскольку ссылок на bar нет, она тут же удаляется. Таким образом остаётся только один объект — FD bar, ссылка на который и присваивается переменной foo.

    В-третьих, касаемо косвенной ссылки функции на саму себя — посредством arguments.callee, опять же, в случае описания NFE с сохранением ссылки на неё в переменную по месту (т.е. использованием двух объектов), arguments.callee будет указывать на тот объект, чьим именем была активирована функция (а точнее — функции, т.к. их две):

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

    Данное поведение также можно “логично” разобрать. При входе в контекст была создана последняя встретившаяся “FD” для имени bar, т.е. функция с alert(2);. Далее, при интерпретации кода, создаётся уже новая функция — FE bar, ссылка на которую и присваивается переменной foo. Таким образом (поскольку дальше по коду if-блок с условием false — недостижим), активация foo выводит alert(1);. Логика ясна, но с учётом багов IE, я взял слово “логично” в кавычки, т.к. подобная реализация явно сбитая и завязана на баги JScript.

    Ну и пятый баг NFE в JScript связан с инициализацией свойств глобального объекта посредством обычного присвоения имени значения. Т.к. NFE трактуется здесь как FD и, соответственно, попадает в объект переменных, присвоение ссылки свойству без var (т.е. не переменной, а обычному свойству глобального объекта), при условии, что имя самой функции совпадает с именем свойства, данное свойство не становится глобальным.

    Опять же, “логика” понятна: декларация функции foo попадает в объект активации локального контекста анонимной функции ещё при входе в контекст. И к моменту интерпретации кода контекста, имя foo уже содержится в AO, т.е. считается локальным. Соответственно, при операции присваивания просто обновляется, уже существующее в AO свойство “foo”, но не создаётся новое свойство глобального объекта, как должно быть по логике вещей ECMA-262-3.

    Функции, созданные конструктором Function

    Данный тип объектов-функций обособлен от FD и FE, т.к. также имеет свои особенности. Основная особенность – это то, что данные функции в качестве [[Scope]] имеют лишь глобальный объект:

    Т.е. видим, что в [[Scope]] функции “bar” отсутствует AO контекста функции “foo” (не доступна переменная “y”, а переменная “x” берётся из глобального контекста). Кстати, обратите внимание, конструктор Function можно вызывать и с new и без, в данном случае эти записи будут эквивалентны.

    Следующая особенность данных функций связана с тождественными правилами грамматики (Equated Grammar Productions) и объединёнными объектами (Joined Objects). Данный механизм введён спецификацией, как предложение по оптимизации (однако, реализации вправе не осуществлять данную оптимизацию). К примеру, если у нас есть массив из ста элементов, который заполняется в цикле функциями, реализация вправе задействовать механизм объединённых объектов. В итоге, может быть создана лишь одна функция для всех элементов массива:

    Но, функции, порождённые конструктором Function, никогда не объединяются:

    Ещё пример, касающийся объединения:

    Здесь также, реализация вправе объединить объекты x и y (и использовать один объект), поскольку функции физически (включая их внутреннее свойство [[Scope]]) не различимы. Поэтому, функции, порождённые с помощью конструктора Function всегда более затратны по ресурсам.

    Алгоритм создания функций

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

    Обратите внимание, F.[[Prototype]] – это прототип функции (конструктора), а F.prototype – это прототип порождаемых от функции объектов (просто часто бывает путаница в терминологии, и F.prototype называют “прототипом конструктора”, что неверно).

    Заключение

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

    Дополнительная литература

    Автор: Dmitry A. Soshnikov.
    Дата публикации: 08.07.2009

    dmitrysoshnikov.com