ECMAscript — это чистая (эталонная) реализация стандарта (возможно, без хост-среды). В таком виде, используется редко где. В качестве конкретного примера можно привести часть стандартной библиотеки невышедшего ES4 (JS 2.0) — в исходниках можно видеть множество файлов с расширением .es ;)
Почитал комменты — всё-таки забавно, как подаётся и воспринимается информация. Автор статьи, не являясь автором Coffeescript-a, пытается его отстаивать, как будто имеет к нему особое отношение (кроме как пользователя). Комментирующие с категоричным видом думают, что им что-то навязывают и (зачем-то) отстаивают Си-подобный синтаксис, как будто имеют к нему какое-то отношение (кроме как пользователей).
Автору: не распинайтесь Вы особо. Предоставили информацию, осветили — всё. Дальше люди сами решат, будут они это использовать или нет. Анализируйте со стороны — умейте видеть плюсы и минусы. Не принимайте какую-то конкретную сторону по причине, что Вы — не автор Coffeescript-a; Вы можете его осветить и рассказать, что к чему, не нарываясь на «консерваторов» (как Вы сами отмечаете).
Кстати, клянчить где-то карму (или, тем более, просить кого-то заминусовать), всё-таки, некрасиво. За такое вот уже можно и послать (с Хабра; хотя, я понимаю, что это проблема Хабра и 80% так поступают — это нужно искоренять).
Тем, кто отвечает — не нравится что-то — не используйте, вам навязывает что ли кто-то? Че вы накинулись на автора статьи, как на автора Coffeescript-a, который как будто навязывает вам этот Coffeescript в ваши текущие проекты? Какой смысл минусовать ему карму?
По теме: я не буду использовать ;) Хоть Ruby и Python мне очень нравятся. Но больше мне нравится JS. С учётом того, что я знаю JS достаточно хорошо, у меня также будут сомнения по поводу качестве сгенерированного кода.
P.S.: Да, и сниппеты с автокомплитом в редакторе, всё-таки, рулят ;)
Сюжет, конечно, «детско»-слащавый, но на графику-то кто тут наезжает (либо воспринимает как должное с умным видом графико-кино-критика)? Какой ещё фильм на сегодня сделан так высокотехнологично в плане графики?
Мир в ультрафиолете очень красивый (хотя, иной раз напоминал ширпотребные лампы с пучком светящихся волокон, продавались такие раньше (может и сейчас есть, не знаю ;))).
К сюжету смысла придираться нет, т.к. он позиционируется как красивая сказка. В отличии от того же «Района №9», который позиционировался, как научная фантастика (с сюжет, по мне, очень примитивный и полный ляпов).
В сравнении с «2012», который, по сюжету, ну никак, не оправдал всю рекламную акцию (фильм — на раз), «Аватар» вполне интересен и красив.
Хотя, может такое впечатление, потому что я первый раз был в 3D ещё? В 4D был до этого (3D + эффекты + спец.кресло). Сначала глаза не могли сфокусироваться, отвлекало, но потом привыкли.
Парсер слово javascript съел (защита от XSS). Вместо буквы «с» написал "&/#99;" Причем, если использовать тег «а» с href="...". Выше написал просто ссылку — там не съел.
Если примеры приведенные в статье мне непонятны (т.е. я не могу не запуская бразуер понять что произойдет, а могу только лишь догадываться) — то эта статья не помечается как мусор
Но я именно это и хотел отметить. Просто от уровня статьи, она не становится «мусором». Мусором она может стать, когда в ней пишется откровенный бред (если ещё позиционировать статью, как профессиональную, её «мусорность» в данном случае ещё больше укрепляется).
Тут дело в том, что иногда, в прикладных статьях, используется упрощение терминологии в угоду большей ясности и простоты изложения (кодовое название: «литература для студентов»). Т.е. может быть переврана официальная терминология и очень упрощенны описания механизмов, но, цель — чтобы студент понял основную суть и мог писать прикладные программы. Такая литература может также позиционироваться, как профессиональная (с прикладной точки зрения).
В теоретических углублённых статьях (кодовое название: «труды для коллег-профессоров»), это уже недопустимо. Там важна точность информации, в ущерб массовой аудитории (поскольку на каждому интересно изучать (любой) предмет глубоко).
Так вот с Вашей позиции («если мне понятны все примеры» статей первого уровня) я должен назвать практически все статьи — мусором. Но это не так. Это просто статьи другого плана, у них другая цель.
Даже в бумажных книгах иногда пишут сзади на обложке: «Уровень: начинающие» или «Уровень: опытные/профессионалы» (например, издательство «Питер» так делало).
> Если вам нравится выискивать информацию среди потоков откровенного говна, что ж, я Вас понять так и не смогу.
Моя цель образовательная. Если человек пишет статью, он вкладывает в неё творческий процесс. То, что он пока на среднем уровне понимания технологии — это другой вопрос. И именно этот уровень поднимется за счет комментариев. Но комментариев не вашего плана. Я лишь отметил категоричный тон, как будто «вы знаете как надо, а статья — говно». Я не прав? Вы, кстати, не ответили, что такое «очень расходится с реальностю в которой мы живем». Но да ладно, меня это не столь волнует уже.
> То, что творится сейчас в мире JS (перечитал ну несравненно много мусора в интернетах когда пытался понять как же работает этот замечательный язык)- так это вообще какое-то безумие
А насколько глубоко вы различаете мусор от немусора в ES? Какова планка? Я ж отметил, статьи бывают разного уровня. В данном случае, у автора — статья: (а) прикладного уровня, (б) разбирающая основы, (в) разбирающая основы поверхностно; (г) полная технических ошибок — но это уже на более углублённом уровне, который автор не затрагивает.
Меня же всегда интересует вопрос справедливой оценки ;)
P.S.:
> Которое по большей части является плодом догадок разработчиков которые даже и не понимают фундаментальных основ данного языка
Вот вам «по меньшей части»: javascript.ru/ecmascript-in-detail (автор этих статей понимает фундаментальные основы JS; прошу простить, за то, что обратился к себе в третьем лице).
Переменные в Javascript бывают глобальными и локальными. Глобальная переменная доступна везде, локальная — только в текущей области видимости.
Да, можно и так сказать. Технически же, большой разницы — глобальные/локальные — нет, механизм одинаковый. Есть только цепочка областей видимости, связанная с активным в данный момент контекстом исполнения, и в этой цепочке ищутся переменные — начиная из самого глубокого (активного) контекста — и вверх — до глобального.
Технически, глобальные переменные — всего лишь свойства объекта window, поскольку весь код выполняется в его контексте.
Да, для упрощённого описания, и для browser scripting, можно и так сказать. Но надо понимать, что глобальные переменные — это, по стандарту, свойства глобального объекта, а не window. И, хоть в стандарте сказано, что window в DOM-модели — это рекурсивная ссылка на глобальный объект, в действительности это не всегда так. По факту же, да, обращение к свойствам window будет возвращать переменные глобального контекста.
При присвоении значения неопределенной локальной переменной используется или создается глобальная переменная.
Вот самая распространённая ошибка (опять же, с технической точки зрения). Запомните, переменные объявляются только с ключевым словом var. Присвоение же вроде:
a = 10;
лишь создаёт очередное свойство (но не переменную) в глобальном объекте. «Не переменную» не в том смысле, что её нельзя изменить, а «не переменную» в понятии переменных в ECMAscript. То, что в обоих случаях, это будут свойства глобального объекта — это уже следствие. Но, есть существенная разница между присвоением неопределённому идентификатору и объявлением переменной. Подробней.
Но для упрощённого описания и предостережения, Ваше описание подойдёт.
Явно объявлять переменные можно и нужно ключевым словом var
Можно убрать слова «явно» и «можно» ;)
Передача кода по старинке — строкой, которая прогоняется через eval() — не попадает под это правило, код исполняется в той области видимости, где и определен.
На самом деле, это связано с тем, что в этом случае создаётся функция, как если бы «new Function», а такие функции имеют в качестве [[Scope]] только глобальный объект. Подробней.
var a = 10;
(function () {
var a = 100;
setTimeout('alert(a);', 0); // 10, а не 100
})();
Поэтому, конечно, удобней использовать в setTimeout-e сразу объект-функцию, а не строку.
Поскольку объекты в Javascript — это тоже типа функции, то свойство объекта определяется точно так же, как и переменная.
function myObject() {
var property = 0;
// Cамо собой, property будет доступно только внутри объекта.
}
Ну здесь Вы, конечно, отсебятину написали ;)
Функции — это тоже (типа) объекты. Обычные объекты, ничем не отличающиеся (кроме внутренних свойств) от других объектов.
Не определяется «свойство объекта, как переменная» в данном случае. Если бы Вы говорили о глобальном контексте, тогда да — объявляя переменную, Вы создаёте свойство глобального объекта.
Иначе можно подумать, Вы имеете в виду, говоря о «свойстве объекта» в данном примере, что-то типа «myObject.property».
var — в контексте функции создаёт свойство в объекте переменных контекста функции. Дальше, если ссылок на этот объект переменных нет, он уничтожается. Если есть (например, замыкание) — остаётся существовать.
А еще в Javascript область видимости переменной ограничивается только функциями, а не блоками типа if (привет, Паскаль). Потому удобнее всего объявлять переменные в начале функции.
Есть такая практика у некоторых (поскольку, технически, действительно, var-ы парсятся при входе в контекст и доступны на протяжении всего контекста, независимо от того, объявили ли мы их в блоке if или нет). Хотя, иной раз удобней объявить переменную по месту.
А что this?
А this — вообще больная тема многих начинающих программировать на JS. Главное, что нужно запомнить, что this всегда определяется при вызове кода контекста и передаётся вызывающей стороной (caller-ом). Уже сходу обычную функцию можно вызвать с двумя разными значениями this (по форме выражения вызова):
function f() {
alert(this);
}
f(); // global (window)
f.prototype.constructor(); // f.prototype
Но вообще, это отдельная большая тема. Если интересно — можете почитать подробней (хотя, именно эту заметку я планирую переработать).
Относительная оценка. А выдаётся за абсолютную. Если автор связан c языком/технологией на определённом уровне, который позволит ему понять основную суть происходящего (без вникания в тонкости), то для очень простого объяснения (как автор и подаёт), сгодилось бы. Тот уровень, с которого рассматриваете Вы, тоже относительный, так же, кто-нибудь может сказать, что всё, что Вы расскажете, будет расходится с более глубоким уровнем.
Технические, конечно, в статье много неверно описано. Но, это удобный вариант для изучающих — они пишут статьи определённого уровня (среднего, выше/нижу среднего и т.д.) и сами учатся на этом.
А о чём именно говорите Вы — про «очень расходится с реальностю в которой мы живем»?
Блин, классная стилизация и сюжетная линия (включая звуковую), когда люди заходят со своими компами — начиная с 0:57 =) Типа, на «священную миссию» прибыли =)
Хорошее «пост»-invitation ;) Правда, по видео больше складывается впечатление, там больше геймеров, нежели демо-сценщиков. Материала по демо-сценам нет?
Сегодня делают классные стилизованные видео с качественным (и сюжетным) звуком, красиво. Но меня так же впечатляли такие invitation-ы, как, например, ".fr-037: The Code Indise" от Farb-rausch и MFX — на Breakepoint 2004 — тоже классно — так же показывается, что будет/было на фестивале + сзади бэкграундом идёт ассемблерный код — это вдохновляет ;)
Забавное решение ;) Но Scope chain, т.е. несколько вложенных функций, уже не создать. Уже больше года не программировал на PHP (5.3а. застал ещё с замыканиями), так что, интересно было вспомнить. Спасибо. По поводу параметров call_user_func_array, которые передаются по значению — тоже полезная информация, равно как и трюк с debug_backtrace.
> На самом деле индексом в массиве объектов является примитив, так что проверка нужна.
Да нет, я имею в виду, Вы пишите:
# object2 = new Number(object2 * 1);
# object2.publicMethod();
…
И можно не опасаться, что кто-то переопределит номер объекта — сервер откажет такому запросу (см. две последние стоки)
И так понятно, что «object2» теперь совершенно независимый (новый) объект и у него нет никакого метода «publicMethod», зачем писать про то, что «сервер откажет», если object2 никак не связан с сервером?
Ну и (просто для справки) — ключами объекта (включая массивы) являются всегда строки, т.е. не просто примитив, а именно примитив-строка.
> А как? Чесслово, интересно
Например, в Spidermonkey до версии 1.7, eval-у можно передать вызывающий контекст, тем самым получая доступ к внутреннему объекту переменных.
function A() {
var x = 10; // "private"
this.getX = function () {
return x;
};
}
var a = new A;
a.getX(); // 10
eval('x = 20', a.getX);
a.getX(); // 20
Интересное решение, своеобразное ;). А какова основная цель? Публичные (external) свойства копируются, что увеличивает расход ресурсов.
> if(objects[_id].Eexternal
Опечатка.
> И можно не опасаться, что кто-то переопределит номер объекта — сервер откажет такому запросу (см. две последние стоки)
Ну блин, ещё бы, совершенно новый независимый объект Number создаётся, никак не связанный с данной обёрткой (не имеющий расширенных, скопированных свойств) ;)
В целом, не считая недочётов, что extenral stuff копируется в каждый новый объект, а не наследуется, а также, не считая того, что в некоторых реализациях, всё-таки, можно получить доступ к инкапсулированному var-у «objs» и обратиться к нужному «скрытому» объекту, — идея своеобразно-интересная ;)
P.S.: немного затрагивал тему инкапсуляции (с позиции восприятия) в седьмой части статей об ECMAscript.
> Код функций никогда не копируется, поэтому от их размера ничего не зависит.
Зависит от типа функции. Стандарт предусматривает оптимизацию в виде объединённых объектов, но там должны соблюдаться определённые условия. Новая версия стандарта (ECMA-262-5, текущий драфт) определяет внутреннее свойство [[Code]], которое может реюзаться между (объединёнными) функциями, но в текущей версии стандарта об этом ничего не сказано (хотя, на практике, я думаю, реализации делают оптимизацию, включая предложенную с объединёнными объектами). Но, повторю, зависит это от типа функций. Разбирал это в пятой части статей об ECMAscript.
Самый первый пункт из ECMA-262-3:
Javascript (trade mark) — название языка от (Spider)monkey engine, Jscript — от Microsoft и т.д.
Кстати, самому B.Eich-у (создатель Javascript), название ECMAscript никогда не нравилось ;)
Вообще, ECMAscript — это язык программирования, а стандарт — это ECMA-262 (текущая версия 5).
Самый первый пункт из ECMA-262-3:
Автору: не распинайтесь Вы особо. Предоставили информацию, осветили — всё. Дальше люди сами решат, будут они это использовать или нет. Анализируйте со стороны — умейте видеть плюсы и минусы. Не принимайте какую-то конкретную сторону по причине, что Вы — не автор Coffeescript-a; Вы можете его осветить и рассказать, что к чему, не нарываясь на «консерваторов» (как Вы сами отмечаете).
Кстати, клянчить где-то карму (или, тем более, просить кого-то заминусовать), всё-таки, некрасиво. За такое вот уже можно и послать (с Хабра; хотя, я понимаю, что это проблема Хабра и 80% так поступают — это нужно искоренять).
Тем, кто отвечает — не нравится что-то — не используйте, вам навязывает что ли кто-то? Че вы накинулись на автора статьи, как на автора Coffeescript-a, который как будто навязывает вам этот Coffeescript в ваши текущие проекты? Какой смысл минусовать ему карму?
По теме: я не буду использовать ;) Хоть Ruby и Python мне очень нравятся. Но больше мне нравится JS. С учётом того, что я знаю JS достаточно хорошо, у меня также будут сомнения по поводу качестве сгенерированного кода.
P.S.: Да, и сниппеты с автокомплитом в редакторе, всё-таки, рулят ;)
Мир в ультрафиолете очень красивый (хотя, иной раз напоминал ширпотребные лампы с пучком светящихся волокон, продавались такие раньше (может и сейчас есть, не знаю ;))).
К сюжету смысла придираться нет, т.к. он позиционируется как красивая сказка. В отличии от того же «Района №9», который позиционировался, как научная фантастика (с сюжет, по мне, очень примитивный и полный ляпов).
В сравнении с «2012», который, по сюжету, ну никак, не оправдал всю рекламную акцию (фильм — на раз), «Аватар» вполне интересен и красив.
Хотя, может такое впечатление, потому что я первый раз был в 3D ещё? В 4D был до этого (3D + эффекты + спец.кресло). Сначала глаза не могли сфокусироваться, отвлекало, но потом привыкли.
В технологичном плане, «Аватар» — очень крут.
Но я именно это и хотел отметить. Просто от уровня статьи, она не становится «мусором». Мусором она может стать, когда в ней пишется откровенный бред (если ещё позиционировать статью, как профессиональную, её «мусорность» в данном случае ещё больше укрепляется).
Тут дело в том, что иногда, в прикладных статьях, используется упрощение терминологии в угоду большей ясности и простоты изложения (кодовое название: «литература для студентов»). Т.е. может быть переврана официальная терминология и очень упрощенны описания механизмов, но, цель — чтобы студент понял основную суть и мог писать прикладные программы. Такая литература может также позиционироваться, как профессиональная (с прикладной точки зрения).
В теоретических углублённых статьях (кодовое название: «труды для коллег-профессоров»), это уже недопустимо. Там важна точность информации, в ущерб массовой аудитории (поскольку на каждому интересно изучать (любой) предмет глубоко).
Так вот с Вашей позиции («если мне понятны все примеры» статей первого уровня) я должен назвать практически все статьи — мусором. Но это не так. Это просто статьи другого плана, у них другая цель.
Даже в бумажных книгах иногда пишут сзади на обложке: «Уровень: начинающие» или «Уровень: опытные/профессионалы» (например, издательство «Питер» так делало).
В целом, да, Ваша позиция ясна. Спасибо, успехов.
Моя цель образовательная. Если человек пишет статью, он вкладывает в неё творческий процесс. То, что он пока на среднем уровне понимания технологии — это другой вопрос. И именно этот уровень поднимется за счет комментариев. Но комментариев не вашего плана. Я лишь отметил категоричный тон, как будто «вы знаете как надо, а статья — говно». Я не прав? Вы, кстати, не ответили, что такое «очень расходится с реальностю в которой мы живем». Но да ладно, меня это не столь волнует уже.
> То, что творится сейчас в мире JS (перечитал ну несравненно много мусора в интернетах когда пытался понять как же работает этот замечательный язык)- так это вообще какое-то безумие
А насколько глубоко вы различаете мусор от немусора в ES? Какова планка? Я ж отметил, статьи бывают разного уровня. В данном случае, у автора — статья: (а) прикладного уровня, (б) разбирающая основы, (в) разбирающая основы поверхностно; (г) полная технических ошибок — но это уже на более углублённом уровне, который автор не затрагивает.
Меня же всегда интересует вопрос справедливой оценки ;)
P.S.:
> Которое по большей части является плодом догадок разработчиков которые даже и не понимают фундаментальных основ данного языка
Вот вам «по меньшей части»: javascript.ru/ecmascript-in-detail (автор этих статей понимает фундаментальные основы JS; прошу простить, за то, что обратился к себе в третьем лице).
Да, можно и так сказать. Технически же, большой разницы — глобальные/локальные — нет, механизм одинаковый. Есть только цепочка областей видимости, связанная с активным в данный момент контекстом исполнения, и в этой цепочке ищутся переменные — начиная из самого глубокого (активного) контекста — и вверх — до глобального.
Да, для упрощённого описания, и для browser scripting, можно и так сказать. Но надо понимать, что глобальные переменные — это, по стандарту, свойства глобального объекта, а не window. И, хоть в стандарте сказано, что window в DOM-модели — это рекурсивная ссылка на глобальный объект, в действительности это не всегда так. По факту же, да, обращение к свойствам window будет возвращать переменные глобального контекста.
Вот самая распространённая ошибка (опять же, с технической точки зрения). Запомните, переменные объявляются только с ключевым словом var. Присвоение же вроде:
лишь создаёт очередное свойство (но не переменную) в глобальном объекте. «Не переменную» не в том смысле, что её нельзя изменить, а «не переменную» в понятии переменных в ECMAscript. То, что в обоих случаях, это будут свойства глобального объекта — это уже следствие. Но, есть существенная разница между присвоением неопределённому идентификатору и объявлением переменной. Подробней.
Но для упрощённого описания и предостережения, Ваше описание подойдёт.
Можно убрать слова «явно» и «можно» ;)
На самом деле, это связано с тем, что в этом случае создаётся функция, как если бы «new Function», а такие функции имеют в качестве [[Scope]] только глобальный объект. Подробней.
var a = 10; (function () { var a = 100; setTimeout('alert(a);', 0); // 10, а не 100 })();Поэтому, конечно, удобней использовать в setTimeout-e сразу объект-функцию, а не строку.
Ну здесь Вы, конечно, отсебятину написали ;)
Функции — это тоже (типа) объекты. Обычные объекты, ничем не отличающиеся (кроме внутренних свойств) от других объектов.
Не определяется «свойство объекта, как переменная» в данном случае. Если бы Вы говорили о глобальном контексте, тогда да — объявляя переменную, Вы создаёте свойство глобального объекта.
Иначе можно подумать, Вы имеете в виду, говоря о «свойстве объекта» в данном примере, что-то типа «myObject.property».
var — в контексте функции создаёт свойство в объекте переменных контекста функции. Дальше, если ссылок на этот объект переменных нет, он уничтожается. Если есть (например, замыкание) — остаётся существовать.
Есть такая практика у некоторых (поскольку, технически, действительно, var-ы парсятся при входе в контекст и доступны на протяжении всего контекста, независимо от того, объявили ли мы их в блоке if или нет). Хотя, иной раз удобней объявить переменную по месту.
А this — вообще больная тема многих начинающих программировать на JS. Главное, что нужно запомнить, что this всегда определяется при вызове кода контекста и передаётся вызывающей стороной (caller-ом). Уже сходу обычную функцию можно вызвать с двумя разными значениями this (по форме выражения вызова):
function f() { alert(this); } f(); // global (window) f.prototype.constructor(); // f.prototypeНо вообще, это отдельная большая тема. Если интересно — можете почитать подробней (хотя, именно эту заметку я планирую переработать).
Успехов в изучении ES.
Технические, конечно, в статье много неверно описано. Но, это удобный вариант для изучающих — они пишут статьи определённого уровня (среднего, выше/нижу среднего и т.д.) и сами учатся на этом.
А о чём именно говорите Вы — про «очень расходится с реальностю в которой мы живем»?
Сегодня делают классные стилизованные видео с качественным (и сюжетным) звуком, красиво. Но меня так же впечатляли такие invitation-ы, как, например, ".fr-037: The Code Indise" от Farb-rausch и MFX — на Breakepoint 2004 — тоже классно — так же показывается, что будет/было на фестивале + сзади бэкграундом идёт ассемблерный код — это вдохновляет ;)
Эта ветка на первый взгляд кажется лишней.
Да нет, я имею в виду, Вы пишите:
И так понятно, что «object2» теперь совершенно независимый (новый) объект и у него нет никакого метода «publicMethod», зачем писать про то, что «сервер откажет», если object2 никак не связан с сервером?
Ну и (просто для справки) — ключами объекта (включая массивы) являются всегда строки, т.е. не просто примитив, а именно примитив-строка.
> А как? Чесслово, интересно
Например, в Spidermonkey до версии 1.7, eval-у можно передать вызывающий контекст, тем самым получая доступ к внутреннему объекту переменных.
function A() { var x = 10; // "private" this.getX = function () { return x; }; } var a = new A; a.getX(); // 10 eval('x = 20', a.getX); a.getX(); // 20> if(objects[_id].Eexternal
Опечатка.
> И можно не опасаться, что кто-то переопределит номер объекта — сервер откажет такому запросу (см. две последние стоки)
Ну блин, ещё бы, совершенно новый независимый объект Number создаётся, никак не связанный с данной обёрткой (не имеющий расширенных, скопированных свойств) ;)
В целом, не считая недочётов, что extenral stuff копируется в каждый новый объект, а не наследуется, а также, не считая того, что в некоторых реализациях, всё-таки, можно получить доступ к инкапсулированному var-у «objs» и обратиться к нужному «скрытому» объекту, — идея своеобразно-интересная ;)
P.S.: немного затрагивал тему инкапсуляции (с позиции восприятия) в седьмой части статей об ECMAscript.
Зависит от типа функции. Стандарт предусматривает оптимизацию в виде объединённых объектов, но там должны соблюдаться определённые условия. Новая версия стандарта (ECMA-262-5, текущий драфт) определяет внутреннее свойство [[Code]], которое может реюзаться между (объединёнными) функциями, но в текущей версии стандарта об этом ничего не сказано (хотя, на практике, я думаю, реализации делают оптимизацию, включая предложенную с объединёнными объектами). Но, повторю, зависит это от типа функций. Разбирал это в пятой части статей об ECMAscript.