>к чему еще привешивать ярлык "класса", как ни к конструктору
С большущей натяжкой можно было бы "прилепить" это ярлык к связке конструктор и прототип. Однако все-равно будет не верно. Представьте, что можно "творить" с конструкторами и прототипами в run-time в J(ava)Script и возможно ли такое, применительно к классам (ну хотя бы в самом страшном сне "classical"-программиста).
>Кстати, выше я конструктор с классом нигде не сравнивал :)
Как хитро! :) Сами же пишите: "к чему еще привешивать ярлык "класса", как ни к конструктору"...
>Я думал это известная всем поговорка, смысл которой должен быть ясен =)
А поговорка, как говориться, мимо нот. Автор не утверждал, что он изобрел велосипед. Он лишь смастерил свой, неповторимый в контексте хабра и не только (его велосипед легок, прост в управлении в сравнении с профессиональными моделями).
>Если цель быстро и качественно решить поставленную задачу...
>В начале топика написано…
Там же есть и то, что Вы упустили из виду: "Пройдясь по хабра-поиску выяснил...". Поэтому Вы напрасно гадаете, какие у автора цели – они определены совершенно четко и ясно.
>И с этой точки зрения время вседаки потрачено зря.
С подобной точкой зрения я сталкивался не раз. Мне тоже писали: "Заче-е-ем? Возьми готовое". Доходило даже до: "Может свою ось возьмешься писать?". А я думаю так, что это программиста не касается. Ему если понадобилось или заставили – он написал, а если сказали взять какую-то либу, то он так и делает. Так что "советы", подобные вашим, его не волнуют, т.к. это просто-напросто не по адресу.
>...не стоит изобретать велосипед, только зря время потратишь...
Интересная точка зрения. А все велосипеды в мире изобретены/созданы одним производителем?
Человек ведь пишет для себя, для своих проектов. Сюда выкладывает, чтобы народ потестировал и т.п. А Вы ему - зачем это нужно...
Да с переменными-то разобрались. Я уже о том, что js'овская функция-конструктор не может (ну ни-и-и как) называться классом (хоть как это слово закавычивать)...
Кстати, почти на эту тему (классы и т.п.) сегодня, отвечая одному из своих собеседников, цитировал Big Gungs of JS - прочтите, если есть время.
>…пространство имён это и есть неповторимый объект :)
Дайте ссылочку почитать о том, что namespace – это объект. ;)
>…локальные переменные конструктора становятся не "приватными" свойствами объекта, а приватными статическими свойствами "класса".
Нет, во-первых, все же локальные переменные конструктора – это private instance members (если уж дошло до class-based терминологии). Во-вторых, в ES3-программе можно создать приватные статические св-ва чего-угодно (конструктора, прототипа, экземпляра), но только не класса, потому что классов в ES3 не существует.
А вообще, изначально хотел просто заметить, что создаете совершенно отличные друг от друга структуры, предназначающиеся для разных целей.
Вы комментируете фрагмент кода, в котором создается конструктор, который, в свою очередь, может "породить" множество объектов. У Вас - лишь создание одного единственного и неповторимого объекта.
>…ощущаю какой-то выраженный протест. Я где-то чего-то не так понимаю? :)
Ваши ощущения Вас обманывают. Не воспринимайте комментарии лично (это на будущее). Пусть они будут для Вас той благодатной почвой, на которой могут появиться новые мысли или нечно подобное (в смысле, полезное).
>…мне не совсем понятен смысл Вашей мысли…
>…следовало добавить "отсебятину" в виде уточнения, что уклон статьи - Ext JS.
Да, точно – так и надо было. Я-то все воспринял в контексте: "большинство web-приложений состоят из большого числа библиотек, виджетов и сниппетов из многих и многих источников" (со всеми "вытекающими").
> Ext.namespace создаст объекты с переданными именами, если они еще не существуют
> Определение MySingleton внутри пакета App.data
А если объекты существуют, да еще и, например, внутри "пакета" App.data уже есть св-во MySingleton, тогда что?
Нет, все-же в отсутствие необходимых инструментов для органиции подобных структур (namespaces и т.п.) хочешь или не хочешь, а "подглядывать" в чужие скрипты придется для того, чтобы создавать уникальные идентификаторы.
>хеши в 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 "достанет" свойства еще и из цепи прототипов.
Ну а с массивами-то нет такого, так ведь? А Вы писали, что "перечисление элементов массива... не должно завершаться запятой (это приведёт к ошибке)".
Именно то, что касается массивов, я и хотел "подправить"...
>В статье для C++-програмистов именно так и будет написано ;)
И это будет ошибкой.
Я сейчас нашел пару руководств, с которых начинал знакомство с J(ava)Script. Так вот, что мне в них сразу понравилось, так это то, что с самого начала предлагаются наглядные таблички с описанием основных отличий языков Java и JavaScript (и, следовательно, отличия js от каких-либо других языков). Вот, посмотрите: JavaScript и Java Classical Inheritance in JavaScript
Таким образом, буквально с первых "шагов" знакомства с J(ava)Script становятся понятными концепция и устройство языка. И, как результат, нет желания путать одно с другим...
>Эта статья рассчитана на быстрое погружение 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 и С++ очень и очень похожи...
К вашему сожалению ( ;) ) он все-таки прав. Взять, к примеру, так называемые "замыкания". По-поводу "что такое замыкания и есть ли они (в том виде, к которому привык какой-либо программист) в конкретном языке" в сети можно найти немало споров. Простой вопрос – что именно для Вас замыкание в Perl и в ECMAScript? Действительно ли это одно и тоже, или для совершенно разных конструкций используется (для удобства) один термин?
>Ничего из этого в C/C++ нет.
Вот Вам о замыканиях в <a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf title=>С++.
Так что, считаю абсолютно правыми тех, кто пишет, что следуя вашей логике можно было бы называть все языки похожими. Естественно, при ближайшем рассмотрении, это не верно. Например, Вы пишите: "хэши JavaScript", а в JavaScript нет такого (вообще!!!) – есть объекты, лишь отдаленно напоминающие Вам Perl’овские хэши.
>не припоминаю точно, но что то типа this.arguments
Вот это ваше "не припомню" и есть главное "зло". Поясню.
__ИМЯ_ФУНКЦИИ__.caller – действительно есть в JavaScript(tm), но это свойство не стандартное (т.е. его нет ECMAScript Language Specification). Следовательно, на это св-во рассчитывать нельзя – в той же Opera, к примеру, его нет.
__ИМЯ_ФУНКЦИИ__.arguments – также есть в JavaScript(tm), но его нет в ECMAScript Language Specification. И, как можно прочесть в документации по JavaScript, использование этого св-ва считается крайне нежелательным.
Так что, проводя параллели, Вы допускаете те ошибки, которые могут негативно сказаться на остальных. Это плохо. ;)
Что именно "попробывать"? :)
Если серьезно, то по существу есть что добавить? Т.е. последуют ли комментарии, касающиеся сути вопроса (чтоб о Вас не создалось впечатление: "слышал звон, да не знает, где он" :) )?
С большущей натяжкой можно было бы "прилепить" это ярлык к связке конструктор и прототип. Однако все-равно будет не верно. Представьте, что можно "творить" с конструкторами и прототипами в run-time в J(ava)Script и возможно ли такое, применительно к классам (ну хотя бы в самом страшном сне "classical"-программиста).
>Кстати, выше я конструктор с классом нигде не сравнивал :)
Как хитро! :) Сами же пишите: "к чему еще привешивать ярлык "класса", как ни к конструктору"...
А поговорка, как говориться, мимо нот. Автор не утверждал, что он изобрел велосипед. Он лишь смастерил свой, неповторимый в контексте хабра и не только (его велосипед легок, прост в управлении в сравнении с профессиональными моделями).
>Если цель быстро и качественно решить поставленную задачу...
>В начале топика написано…
Там же есть и то, что Вы упустили из виду: "Пройдясь по хабра-поиску выяснил...". Поэтому Вы напрасно гадаете, какие у автора цели – они определены совершенно четко и ясно.
>И с этой точки зрения время вседаки потрачено зря.
С подобной точкой зрения я сталкивался не раз. Мне тоже писали: "Заче-е-ем? Возьми готовое". Доходило даже до: "Может свою ось возьмешься писать?". А я думаю так, что это программиста не касается. Ему если понадобилось или заставили – он написал, а если сказали взять какую-то либу, то он так и делает. Так что "советы", подобные вашим, его не волнуют, т.к. это просто-напросто не по адресу.
Интересная точка зрения. А все велосипеды в мире изобретены/созданы одним производителем?
Человек ведь пишет для себя, для своих проектов. Сюда выкладывает, чтобы народ потестировал и т.п. А Вы ему - зачем это нужно...
Кстати, почти на эту тему (классы и т.п.) сегодня, отвечая одному из своих собеседников, цитировал Big Gungs of JS - прочтите, если есть время.
Я тоже специально обратил на это внимание. ;)
Везде конструкторы - это конструкторы, а в ES3 с чего-то вдруг они стали классами в кавычках. ;)
Дайте ссылочку почитать о том, что namespace – это объект. ;)
>…локальные переменные конструктора становятся не "приватными" свойствами объекта, а приватными статическими свойствами "класса".
Нет, во-первых, все же локальные переменные конструктора – это private instance members (если уж дошло до class-based терминологии). Во-вторых, в ES3-программе можно создать приватные статические св-ва чего-угодно (конструктора, прототипа, экземпляра), но только не класса, потому что классов в ES3 не существует.
А вообще, изначально хотел просто заметить, что создаете совершенно отличные друг от друга структуры, предназначающиеся для разных целей.
Ваши ощущения Вас обманывают. Не воспринимайте комментарии лично (это на будущее). Пусть они будут для Вас той благодатной почвой, на которой могут появиться новые мысли или нечно подобное (в смысле, полезное).
>…мне не совсем понятен смысл Вашей мысли…
>…следовало добавить "отсебятину" в виде уточнения, что уклон статьи - Ext JS.
Да, точно – так и надо было. Я-то все воспринял в контексте: "большинство web-приложений состоят из большого числа библиотек, виджетов и сниппетов из многих и многих источников" (со всеми "вытекающими").
> Определение MySingleton внутри пакета App.data
А если объекты существуют, да еще и, например, внутри "пакета" App.data уже есть св-во MySingleton, тогда что?
Нет, все-же в отсутствие необходимых инструментов для органиции подобных структур (namespaces и т.п.) хочешь или не хочешь, а "подглядывать" в чужие скрипты придется для того, чтобы создавать уникальные идентификаторы.
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 "достанет" свойства еще и из цепи прототипов.
Именно то, что касается массивов, я и хотел "подправить"...
И это будет ошибкой.
Я сейчас нашел пару руководств, с которых начинал знакомство с J(ava)Script. Так вот, что мне в них сразу понравилось, так это то, что с самого начала предлагаются наглядные таблички с описанием основных отличий языков Java и JavaScript (и, следовательно, отличия js от каких-либо других языков). Вот, посмотрите:
JavaScript и Java
Classical Inheritance in JavaScript
Таким образом, буквально с первых "шагов" знакомства с J(ava)Script становятся понятными концепция и устройство языка. И, как результат, нет желания путать одно с другим...
А какая ошибка?
var a = [,];Длина неправильно определяется или что?
Я это прекрасно понимаю. Более того, я приветствую ваши благие намерения помочь "собратьями по офису" наконец-то окунуться в мир 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 и С++ очень и очень похожи...
К вашему сожалению ( ;) ) он все-таки прав. Взять, к примеру, так называемые "замыкания". По-поводу "что такое замыкания и есть ли они (в том виде, к которому привык какой-либо программист) в конкретном языке" в сети можно найти немало споров. Простой вопрос – что именно для Вас замыкание в Perl и в ECMAScript? Действительно ли это одно и тоже, или для совершенно разных конструкций используется (для удобства) один термин?
>Ничего из этого в C/C++ нет.
Вот Вам о замыканиях в <a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf title=>С++.
Так что, считаю абсолютно правыми тех, кто пишет, что следуя вашей логике можно было бы называть все языки похожими. Естественно, при ближайшем рассмотрении, это не верно. Например, Вы пишите: "хэши JavaScript", а в JavaScript нет такого (вообще!!!) – есть объекты, лишь отдаленно напоминающие Вам Perl’овские хэши.
Вот это ваше "не припомню" и есть главное "зло". Поясню.
__ИМЯ_ФУНКЦИИ__.caller – действительно есть в JavaScript(tm), но это свойство не стандартное (т.е. его нет ECMAScript Language Specification). Следовательно, на это св-во рассчитывать нельзя – в той же Opera, к примеру, его нет.
__ИМЯ_ФУНКЦИИ__.arguments – также есть в JavaScript(tm), но его нет в ECMAScript Language Specification. И, как можно прочесть в документации по JavaScript, использование этого св-ва считается крайне нежелательным.
Так что, проводя параллели, Вы допускаете те ошибки, которые могут негативно сказаться на остальных. Это плохо. ;)
Что именно "попробывать"? :)
Если серьезно, то по существу есть что добавить? Т.е. последуют ли комментарии, касающиеся сути вопроса (чтоб о Вас не создалось впечатление: "слышал звон, да не знает, где он" :) )?
MSDN:
…every bit that is 1 in the operand is 0 in the result. Conversely, every bit that is 0 in the operand is 1 in the result.
т.е. это оператор двоичной инверсии (Bitwise NOT).
Что значит "не зависит", и что значит "тяжелее"?
Вообще, странно читать, что "что-то не зависит", ведь все в руках программиста, не так ли?
>зависит от конкретных задач.
Лично я именно с этого бы и начал. ;)
>для реализации визуальных эффектов лучше использовать setTimeout.
Как понимать это утверждение? Лучше для всех или просто удобней именно для Вас?