Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 80
хм... зачем все это?
Не знаю, за что топик минусуют, а мне лично понравилось
Скорее всего, первые минуса попали на тот момент, когда я запутался в форматировании статьи на хабре.
Для меня это практически первый опыт публикации тут :)
Для меня это практически первый опыт публикации тут :)
может, за то, что в куроводстве написано то же самое (нет, не построчно, но те же самые тезисы вроде JS он как перл), но давно и интереснее? )
упс, куроводство давно не читал :)
посмотрю обязательно.
посмотрю обязательно.
плюсанул, действительно, лучше написано. Сейчас и статью обновлю.
спасибо, хорошая тема. перл выучил, а до жабаскрипта лапки не дошли
Неверная конструкция:
Тут либо:
...либо:
function Something = function ()
{
}
Тут либо:
Something = function ()
{
}
...либо:
function Something ()
{
}
надо перл поучить :)
"Perl и JavaScript очень похожи." - это не правда...
всё новое - это хорошо забытое старое :)
чёрт :)
чёрт :)
Котеров тут не причем, это все Страуструп :) Оба языка — производные С++
Нет, это неправда.
Автор описал пяток сходных примеров, один из которых, к тому же, отличается весьма существенной разницей в поведении (про замыкания).
И не описал примерно пять сотен различий :).
Странно, что не была описано сходство в операторах присваивания и одинаковое поведение операций сложения-умножения :).
Автор описал пяток сходных примеров, один из которых, к тому же, отличается весьма существенной разницей в поведении (про замыкания).
И не описал примерно пять сотен различий :).
Странно, что не была описано сходство в операторах присваивания и одинаковое поведение операций сложения-умножения :).
ну почему же?
perl && js имеют много общего, я б сказал.
похоже создаются функции/процедуры (... описано в топике.) в js тоже можно передавать список аргументов, подобно @_ (не припоминаю точно, но что то типа this.arguments или __ИМЯ_ФУНКЦИИ__.arguments; тоже есть аналог caller: __ИМЯ_ФУНКЦИИ__.caller && __ИМЯ_ФУНКЦИИ__.caller.arguments)...
тоже есть ламбда-выражения (поправте меня, если я не то назвал):
perl: sub getBar { my $beep = $_[0]; my $func = sub { print $beep . " " . $_[0]; } }; $foo = getBar("Hello "); &$foo("world!!!"); # выведет "Hello world!!!"
js: function getBar() { var beep = getBar.arguments[0]; return (function(foo) { alert(beep + foo); }); }; var foo = getBar("Hello "); foo("world!!!"); // будет окошко из той же самой надписью
... можно наводить еще больше сходств, но нужно ли? на JS, как и на PERL можно написать довольно запутаный код... но JAPH для JS врят-ли можно повторить...
perl && js имеют много общего, я б сказал.
похоже создаются функции/процедуры (... описано в топике.) в js тоже можно передавать список аргументов, подобно @_ (не припоминаю точно, но что то типа this.arguments или __ИМЯ_ФУНКЦИИ__.arguments; тоже есть аналог caller: __ИМЯ_ФУНКЦИИ__.caller && __ИМЯ_ФУНКЦИИ__.caller.arguments)...
тоже есть ламбда-выражения (поправте меня, если я не то назвал):
perl: sub getBar { my $beep = $_[0]; my $func = sub { print $beep . " " . $_[0]; } }; $foo = getBar("Hello "); &$foo("world!!!"); # выведет "Hello world!!!"
js: function getBar() { var beep = getBar.arguments[0]; return (function(foo) { alert(beep + foo); }); }; var foo = getBar("Hello "); foo("world!!!"); // будет окошко из той же самой надписью
... можно наводить еще больше сходств, но нужно ли? на JS, как и на PERL можно написать довольно запутаный код... но JAPH для JS врят-ли можно повторить...
в JS (вродь как и в PERL, но не проверял еще... ) getBar("Hello ")("world!!"); будет давать тот же результат.
после PERL'ового $bar = someFunction("bla", 0, 2, false, {foo => 'bar'})[2]; (ну или использование &caller) на очень легко было привыкнуть к конструкциям типа obj.getElementsByClassName("foo")[0];
етого мне очень не хватает иногда в PHP.
... но жду выхода PERL 6... там все на порядок иначе:)
после PERL'ового $bar = someFunction("bla", 0, 2, false, {foo => 'bar'})[2]; (ну или использование &caller) на очень легко было привыкнуть к конструкциям типа obj.getElementsByClassName("foo")[0];
етого мне очень не хватает иногда в PHP.
... но жду выхода PERL 6... там все на порядок иначе:)
>не припоминаю точно, но что то типа this.arguments
Вот это ваше "не припомню" и есть главное "зло". Поясню.
__ИМЯ_ФУНКЦИИ__.caller – действительно есть в JavaScript(tm), но это свойство не стандартное (т.е. его нет ECMAScript Language Specification). Следовательно, на это св-во рассчитывать нельзя – в той же Opera, к примеру, его нет.
__ИМЯ_ФУНКЦИИ__.arguments – также есть в JavaScript(tm), но его нет в ECMAScript Language Specification. И, как можно прочесть в документации по JavaScript, использование этого св-ва считается крайне нежелательным.
Так что, проводя параллели, Вы допускаете те ошибки, которые могут негативно сказаться на остальных. Это плохо. ;)
Вот это ваше "не припомню" и есть главное "зло". Поясню.
__ИМЯ_ФУНКЦИИ__.caller – действительно есть в JavaScript(tm), но это свойство не стандартное (т.е. его нет ECMAScript Language Specification). Следовательно, на это св-во рассчитывать нельзя – в той же Opera, к примеру, его нет.
__ИМЯ_ФУНКЦИИ__.arguments – также есть в JavaScript(tm), но его нет в ECMAScript Language Specification. И, как можно прочесть в документации по JavaScript, использование этого св-ва считается крайне нежелательным.
Так что, проводя параллели, Вы допускаете те ошибки, которые могут негативно сказаться на остальных. Это плохо. ;)
"Perl и JavaScript очень похожи." — после этих слов не читал =)
для Perl-разработчиков эти слова очень важны и необходимы :)
После такого начала люди реально вьезжают в тему.
После такого начала люди реально вьезжают в тему.
ну в любом случае стоит перед этой фразой хотябы добавить что то типа "конструкции языков..."
а то очень мозг режет эта фраза =)
а то очень мозг режет эта фраза =)
Почитал Вашу статью и статью Котерова.
Эмм… я бы понял, если бы они были названы «Схожесть JavaScript и Perl», описаны некоторые мансы схожести в операторах, выражениях.
Но «Perl и JavaScript очень похожи» — это всё-таки далековато от истины. Тем более, что jQuery и Prototype библиотеки, а не собственно JavaScript.
Ну и конечно:
Это такое утончённое издевательство? )) JavaScript обматерит программера рискнувшего объявлять функцию через my ) Не говоря уже о том, что предваряющий знак доллара носит совсем другую смысловую нагрузку нежели в Перле.
Статья, конечно, интересная, но спешить с "очень похожи" я бы не стал.
Эмм… я бы понял, если бы они были названы «Схожесть JavaScript и Perl», описаны некоторые мансы схожести в операторах, выражениях.
Но «Perl и JavaScript очень похожи» — это всё-таки далековато от истины. Тем более, что jQuery и Prototype библиотеки, а не собственно JavaScript.
Ну и конечно:
и JavaScript
my $f = function($a, $b)
{
return $a * $b;
};
Это такое утончённое издевательство? )) JavaScript обматерит программера рискнувшего объявлять функцию через my ) Не говоря уже о том, что предваряющий знак доллара носит совсем другую смысловую нагрузку нежели в Перле.
Статья, конечно, интересная, но спешить с "очень похожи" я бы не стал.
Я уже поправил my на var, - писал по памяти после прошедшего семинара :) ляпы были :)
касательно доллара - есть об этом в статье. Главное - уменьшить порог вхождения.
касательно доллара - есть об этом в статье. Главное - уменьшить порог вхождения.
другую нагрузку? ... можно какой то материал і место где об етом написано? ... ну или напишите сдесь сами, если можете. буду благодарен.
Есть по крайней мере одно важное отличие между ними - ECMAScript очевидно и дальше будет развиваться и пользоваться популярностью, а вот перл нет, потому как не сможет составить конкуренцию Руби/Питону.
Perl никогда не останавливался в развитии, а сообщество Перл программистов становится только шире.
К тому же для Перл есть замечательный MVC фреймворк Catalyst, который очень бурно развивается в последнее время.
К тому же для Перл есть замечательный MVC фреймворк Catalyst, который очень бурно развивается в последнее время.
Про RoR и Django в курсе? Перл изначально был не самым удачным с точки зрения синтаксиса языком, тут впрочем и PHP не далеко от него ушёл. И фреймворком - это не правильное решение подобной проблемы.
По поводу сообщества. Имхо, большинство из этого сообщества сисадмины и любители наваять по-быстрому скриптик с регулярками.
По поводу сообщества. Имхо, большинство из этого сообщества сисадмины и любители наваять по-быстрому скриптик с регулярками.
Увы, ент. Есть очень большое сообщество профессиональных Perl-программистов.
Связано это с большим количеством поддерживаемых проектов, уже написанных на Perl.
Но разработчиков, знающих Perl, найти на рынке всё труднее и труднее (если сравнивать с PHP, RoR, .NET).
Связано это с большим количеством поддерживаемых проектов, уже написанных на Perl.
Но разработчиков, знающих Perl, найти на рынке всё труднее и труднее (если сравнивать с PHP, RoR, .NET).
В курсе. Кстати Catalyst очень близок по задумке и реализации к RoR. Что касается синтаксиса то у него есть свои плюсы. А по поводу сообщества то, пополнение CPAN говорит только об одном, что ряды профессиональных Перл программистов пополняются.
И какие плюсы, если не секрет? В том, что надо помнить про $_ и тому подобное?
Например интерполяция переменных в строку и регулярные выражения без дополнительных операторов. А $_ можно вообще не использовать, если не помните про нее. В Перл можно сделать одну и ту же вещь различными способами, выбор за программистом.
Вот это и есть одна из основных проблем Перла - он избыточен.
Программист при таком разнообразии средств не всегда выбирает наиболее подходящее, а зачастую и вообще пытается доказать, что он ещё и немного хакер и записывает вполне очевидный алгоритм в одну-две строки на беглый взгляд непонятных символов. Поддерживать подобный код потом не очень-то удобно. А взять передачу массива в функцию или другие $* спец. переменные? В общем, я склоняюсь к тому, что Перл очень плохо подходит для промышленной разработки.
Программист при таком разнообразии средств не всегда выбирает наиболее подходящее, а зачастую и вообще пытается доказать, что он ещё и немного хакер и записывает вполне очевидный алгоритм в одну-две строки на беглый взгляд непонятных символов. Поддерживать подобный код потом не очень-то удобно. А взять передачу массива в функцию или другие $* спец. переменные? В общем, я склоняюсь к тому, что Перл очень плохо подходит для промышленной разработки.
ИМХО написать плохо читаемый код можно на любом языке, ровно как и наоборот. Красота и понятность кода зависит не от синтаксиса языка, а от выбранного алгоритма. На мой взгляд в Перл есть все чтобы писать красивый и поддерживаемый код. Плюс документацию на чей-нибудь модуль вы никогда не потеряете потому-что она в него встраивается.
А я сейчас наблюдаю за прогрессом каркаса ASP.NET MVC.
Чем дальше, тем больше хочется перевести все проекты, которые только могу, на .NET :)
Чем дальше, тем больше хочется перевести все проекты, которые только могу, на .NET :)
Собственно, смотреть можно отсюда:
http://weblogs.asp.net/scottgu/archive/2…
http://weblogs.asp.net/scottgu/archive/2…
В таком случае все языки программирования очень похожи. Все используются для формализованной записи алгоритмов. То есть минимально каждый язык содержит функции оперирования данными (любые вычисления, присвоения, индексация массивов и т.п.) и принятия решений (сравнения, условные переходы и т.п.). Синтаксис Perl и JavaScript синтаксически близок к C/C++. Но важно не синтаксичское сходство, а скорей идеологическое. Идеология Perl (и методика программирования, если она для Perl вообще существует =)) далека от JavaScript.
С не меньшим успехом можно склепать "JavaScript и PHP очень похожи" или "JavaScript и C++ очень похожи" (нужно только поправить соответсвующие примеры) и т.п. Можно подумать, что проблемы разработки упираются только в вопрос синтаксиса используемого языка. Ассоциативные массивы, функции, регулярные выражения, ООП и прочий "ширпотреб" в том или ином виде есть практически в любом более-менее развитом и востребованном языке программирования. Тут напрашивается пример с естественными языками: если дословно переводить русские слова на английский — ничего хорошего не получится, менталитет не тот =).
С не меньшим успехом можно склепать "JavaScript и PHP очень похожи" или "JavaScript и C++ очень похожи" (нужно только поправить соответсвующие примеры) и т.п. Можно подумать, что проблемы разработки упираются только в вопрос синтаксиса используемого языка. Ассоциативные массивы, функции, регулярные выражения, ООП и прочий "ширпотреб" в том или ином виде есть практически в любом более-менее развитом и востребованном языке программирования. Тут напрашивается пример с естественными языками: если дословно переводить русские слова на английский — ничего хорошего не получится, менталитет не тот =).
Сожалею, но Вы неправы.
Между Perl и JavaScript есть минимум три точки соприкосновения, не говоря о мелких:
1) Функции-замыкания;
2) Близость по идеологии значений (ссылки н амассивы, хэши и функции);
3) Частично - динамическая типизация.
Ничего из этого в C/C++ нет. И лишь немногое есть в PHP.
Между Perl и JavaScript есть минимум три точки соприкосновения, не говоря о мелких:
1) Функции-замыкания;
2) Близость по идеологии значений (ссылки н амассивы, хэши и функции);
3) Частично - динамическая типизация.
Ничего из этого в C/C++ нет. И лишь немногое есть в PHP.
К сожалению прав, это всё языки программирования, на них пишут программы, и они этим похожи.
Выполняются они все сильно по разному, вот есть в js конструкция doit or die ? Есть волшебные $/ $! $@ ?
Я могу очень и очень долго перечислять то что есть в перле и отсутствует в жаваскрипте.
Ладно, антиоффтопик:
А вы знаете что http://users.fulladsl.be/spb1622/pjs/ ?
А ещё http://search.cpan.org/~rkrimen/Jemplate… ?
Хотя наверное имеет смысл об этом написать отдельно.
Выполняются они все сильно по разному, вот есть в js конструкция doit or die ? Есть волшебные $/ $! $@ ?
Я могу очень и очень долго перечислять то что есть в перле и отсутствует в жаваскрипте.
Ладно, антиоффтопик:
А вы знаете что http://users.fulladsl.be/spb1622/pjs/ ?
А ещё http://search.cpan.org/~rkrimen/Jemplate… ?
Хотя наверное имеет смысл об этом написать отдельно.
>Сожалею, но Вы неправы.
К вашему сожалению ( ;) ) он все-таки прав. Взять, к примеру, так называемые "замыкания". По-поводу "что такое замыкания и есть ли они (в том виде, к которому привык какой-либо программист) в конкретном языке" в сети можно найти немало споров. Простой вопрос – что именно для Вас замыкание в Perl и в ECMAScript? Действительно ли это одно и тоже, или для совершенно разных конструкций используется (для удобства) один термин?
>Ничего из этого в C/C++ нет.
Вот Вам о замыканиях в С++.
Так что, считаю абсолютно правыми тех, кто пишет, что следуя вашей логике можно было бы называть все языки похожими. Естественно, при ближайшем рассмотрении, это не верно. Например, Вы пишите: "хэши JavaScript", а в JavaScript нет такого (вообще!!!) – есть объекты, лишь отдаленно напоминающие Вам Perl’овские хэши.
К вашему сожалению ( ;) ) он все-таки прав. Взять, к примеру, так называемые "замыкания". По-поводу "что такое замыкания и есть ли они (в том виде, к которому привык какой-либо программист) в конкретном языке" в сети можно найти немало споров. Простой вопрос – что именно для Вас замыкание в Perl и в ECMAScript? Действительно ли это одно и тоже, или для совершенно разных конструкций используется (для удобства) один термин?
>Ничего из этого в C/C++ нет.
Вот Вам о замыканиях в С++.
Так что, считаю абсолютно правыми тех, кто пишет, что следуя вашей логике можно было бы называть все языки похожими. Естественно, при ближайшем рассмотрении, это не верно. Например, Вы пишите: "хэши JavaScript", а в JavaScript нет такого (вообще!!!) – есть объекты, лишь отдаленно напоминающие Вам Perl’овские хэши.
Эта статья рассчитана на быстрое погружение Perl-разработчиков - отсюда и смазанность описаний для быстроты понимания.
Кстати, немного о том, что объекты есть хэши, в этой статье также упомянуто :)
P.S.: Спасибо за информацию о замыканиях в C++. Жаль, пока замыканий в C++ нет (да, именно closures - код + окружение).
Кстати, немного о том, что объекты есть хэши, в этой статье также упомянуто :)
P.S.: Спасибо за информацию о замыканиях в C++. Жаль, пока замыканий в C++ нет (да, именно closures - код + окружение).
>Эта статья рассчитана на быстрое погружение Perl-разработчиков - отсюда и смазанность описаний для быстроты понимания.
Я это прекрасно понимаю. Более того, я приветствую ваши благие намерения помочь "собратьями по офису" наконец-то окунуться в мир ECMAScript Language. И именно поэтому я решил указать на некоторые неточности, которые могут мешать в дальнейшем ("смазанность" как-раз ведет к недопониманию).
>Кстати, немного о том, что объекты есть хэши, в этой статье также упомянуто :)
Мало ли что в этой статье упомянуто. ;)
Есть такое, например:
"Перечисление элементов массива/хэша в JavaScript не должно завершаться запятой (это приведёт к ошибке) ".
Это ложное утверждение. Вот, что касается массивов:
ECMAScript Language Specification Edition 3:
11.1.4 Array Initialiser
...
Array elements may be elided at the beginning, middle or end of the element list. Whenever a comma in the element list is not preceded by an AssignmentExpression (i.e., a comma at the beginning or after another comma), the missing array element contributes to the length of the Array and increases the index of subsequent elements. Elided array elements are not defined.
Что касается объектов, то тут, как говорится, "бабушка надвое сказала" – в FF, Safari запятая не станет причиной ошибки, т.к. они уже живут завтрашним днем (ECMAScript 3.1). Но, справедливости ради, надо отметить, что ECMAScript 3 об этом умалчивает (и запятая не должна появляться перед закрывающей скобкой).
Ну а по-поводу хэшей еще раз – ECMAScript native object’s не являются хэшами, какими их может представить Perl-программист.
>Жаль, пока замыканий в C++ нет
Я о "замыканиях" вспомнил лишь по той причине, что нельзя их использовать в качестве обобщающего фактора. В противном случае завтра или послезавтра (или когда там черновик станет частью страндарта C++) можно будет утверждать, что JS и С++ очень и очень похожи...
Я это прекрасно понимаю. Более того, я приветствую ваши благие намерения помочь "собратьями по офису" наконец-то окунуться в мир ECMAScript Language. И именно поэтому я решил указать на некоторые неточности, которые могут мешать в дальнейшем ("смазанность" как-раз ведет к недопониманию).
>Кстати, немного о том, что объекты есть хэши, в этой статье также упомянуто :)
Мало ли что в этой статье упомянуто. ;)
Есть такое, например:
"Перечисление элементов массива/хэша в JavaScript не должно завершаться запятой (это приведёт к ошибке) ".
Это ложное утверждение. Вот, что касается массивов:
ECMAScript Language Specification Edition 3:
11.1.4 Array Initialiser
...
Array elements may be elided at the beginning, middle or end of the element list. Whenever a comma in the element list is not preceded by an AssignmentExpression (i.e., a comma at the beginning or after another comma), the missing array element contributes to the length of the Array and increases the index of subsequent elements. Elided array elements are not defined.
Что касается объектов, то тут, как говорится, "бабушка надвое сказала" – в FF, Safari запятая не станет причиной ошибки, т.к. они уже живут завтрашним днем (ECMAScript 3.1). Но, справедливости ради, надо отметить, что ECMAScript 3 об этом умалчивает (и запятая не должна появляться перед закрывающей скобкой).
Ну а по-поводу хэшей еще раз – ECMAScript native object’s не являются хэшами, какими их может представить Perl-программист.
>Жаль, пока замыканий в C++ нет
Я о "замыканиях" вспомнил лишь по той причине, что нельзя их использовать в качестве обобщающего фактора. В противном случае завтра или послезавтра (или когда там черновик станет частью страндарта C++) можно будет утверждать, что JS и С++ очень и очень похожи...
Почему нет?) В статье для C++-програмистов именно так и будет написано ;)
А про запятую - специально отметил, так как это очень частая ошибка, из-за которой код не раобтает в Internet Explorer 6-7.
А про запятую - специально отметил, так как это очень частая ошибка, из-за которой код не раобтает в Internet Explorer 6-7.
>частая ошибка, из-за которой код не раобтает в Internet Explorer 6-7.
А какая ошибка?
Длина неправильно определяется или что?
А какая ошибка?
var a = [,];Длина неправильно определяется или что?
var a = [3,4,5,];
var b = {a: 4, b: 5};
в Internet Explorer будет ошибка.
var b = {a: 4, b: 5};
в Internet Explorer будет ошибка.
>В статье для C++-програмистов именно так и будет написано ;)
И это будет ошибкой.
Я сейчас нашел пару руководств, с которых начинал знакомство с J(ava)Script. Так вот, что мне в них сразу понравилось, так это то, что с самого начала предлагаются наглядные таблички с описанием основных отличий языков Java и JavaScript (и, следовательно, отличия js от каких-либо других языков). Вот, посмотрите:
JavaScript и Java
Classical Inheritance in JavaScript
Таким образом, буквально с первых "шагов" знакомства с J(ava)Script становятся понятными концепция и устройство языка. И, как результат, нет желания путать одно с другим...
И это будет ошибкой.
Я сейчас нашел пару руководств, с которых начинал знакомство с J(ava)Script. Так вот, что мне в них сразу понравилось, так это то, что с самого начала предлагаются наглядные таблички с описанием основных отличий языков Java и JavaScript (и, следовательно, отличия js от каких-либо других языков). Вот, посмотрите:
JavaScript и Java
Classical Inheritance in JavaScript
Таким образом, буквально с первых "шагов" знакомства с J(ava)Script становятся понятными концепция и устройство языка. И, как результат, нет желания путать одно с другим...
=) Методик программирования на перле много, слишком много для одного человека, и именно по этому перл похож на все языки. То-есть на нём можно писать как на джаваскрипте, можно как на лиспе(я придумал как назвать мой стиль =) ), а можно и как на всём сразу.
Именно это и служит материалом для таких статей.
Именно это и служит материалом для таких статей.
хорошоая статейка по JS...
http://developer.mozilla.org/ru/docs/%D0%9F%D0%BE%D0%B2%D1%82%D0%BE%D1%80%D0%BD%D0%BE%D0%B5_%D0%B2%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_JavaScript
http://developer.mozilla.org/ru/docs/%D0%9F%D0%BE%D0%B2%D1%82%D0%BE%D1%80%D0%BD%D0%BE%D0%B5_%D0%B2%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_JavaScript
JavaScript на Python тоже очень похож, и вроде в разработке второй версии JS опираются на python (не помню где читал, если найду линк подброшу).
я лично сходства не нашол с питоном, ни в циклах, ни в работе с библиотеками, нивчем. Python уникален и неповторим :)
Cейчас не особо много общего, как я и говорил что при разработке второй версии опираются на питон, что не может не радовать. Вот я и линки нашел:
http://ajaxian.com/archives/the-future-of-javascript-an-update-from-brendan-eich
http://weblogs.mozillazine.org/roadmap/archives/2006/02/js_and_python_news.html
http://ajaxian.com/archives/the-future-of-javascript-an-update-from-brendan-eich
http://weblogs.mozillazine.org/roadmap/archives/2006/02/js_and_python_news.html
>и JavaScript
>
>var $f = function($a, $b)
>{
>return $a * $b;
>};
>
>
> Небольшое отличие: при такой форме определения функции в JavaScript после закрывающей фигурной скобки точка с запятой не обязательна.
---
Обязательна точка с запятой, потому что тут переменной присваивается объект-функция, точказапятая не нужна когда создаешь именованую функцию.
Еще перловики удивляются что хеши в js сохраняют последовательность значений, т.е. в цикле for(key in obj) порядок будет тотже что и в присваивании.
>(доступен оператор проверки наличия ключа 'b' in a)
---
в IE5 недоступен. но можно проверить на undefined а еще в нутри условия if(a.b) если это свойство не может быть пустой строкой, null, 0 или false
>
>var $f = function($a, $b)
>{
>return $a * $b;
>};
>
>
> Небольшое отличие: при такой форме определения функции в JavaScript после закрывающей фигурной скобки точка с запятой не обязательна.
---
Обязательна точка с запятой, потому что тут переменной присваивается объект-функция, точказапятая не нужна когда создаешь именованую функцию.
Еще перловики удивляются что хеши в js сохраняют последовательность значений, т.е. в цикле for(key in obj) порядок будет тотже что и в присваивании.
>(доступен оператор проверки наличия ключа 'b' in a)
---
в IE5 недоступен. но можно проверить на undefined а еще в нутри условия if(a.b) если это свойство не может быть пустой строкой, null, 0 или false
>хеши в js сохраняют последовательность значений, т.е. в цикле for(key in obj) порядок будет тотже что и в присваивании.
1. Хэшей в ECMAScript Language не существует.
2. Нельзя рассчитывать, что порядок обхода свойств объекта будет совпадать с порядком их создания:
12.6.4 The for-in Statement:
...
The mechanics of enumerating the properties (step 5 in the first algorithm, step 6 in the second) is implementation dependent.
Proposed ECMAScript 4th Edition – Language Overview:
... ES3 does not specify the order of enumeration in a for-in loop, but Netscape Navigator implemented enumeration order as insertion order and Internet Explorer followed Netscape’s lead.
Сейчас "под рукой" оказалась Opera 7, которая как раз опровергает ваше предположение, подтверждая сказанное в спецификации. И нет никакой гарантии, что этот браузер – единственный в этом отношении.
>>(доступен оператор проверки наличия ключа 'b' in a)
>в IE5 недоступен.
А он (in) и не нужен, если Вы используете объект, как hash table, т.к. оператор in "достанет" свойства еще и из цепи прототипов.
1. Хэшей в ECMAScript Language не существует.
2. Нельзя рассчитывать, что порядок обхода свойств объекта будет совпадать с порядком их создания:
12.6.4 The for-in Statement:
...
The mechanics of enumerating the properties (step 5 in the first algorithm, step 6 in the second) is implementation dependent.
Proposed ECMAScript 4th Edition – Language Overview:
... ES3 does not specify the order of enumeration in a for-in loop, but Netscape Navigator implemented enumeration order as insertion order and Internet Explorer followed Netscape’s lead.
Сейчас "под рукой" оказалась Opera 7, которая как раз опровергает ваше предположение, подтверждая сказанное в спецификации. И нет никакой гарантии, что этот браузер – единственный в этом отношении.
>>(доступен оператор проверки наличия ключа 'b' in a)
>в IE5 недоступен.
А он (in) и не нужен, если Вы используете объект, как hash table, т.к. оператор in "достанет" свойства еще и из цепи прототипов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JavaScript — быстрый старт для Perl-разработчиков