Comments 32
От 21 примочки ожидал что-то сверх новое для себя, но оказалось совсем иначе.
Под таким заголовком стоило на 21 оставить самое вкусное ;)
Под таким заголовком стоило на 21 оставить самое вкусное ;)
По-моему, все эти пункты относятся к любому си-подобному объектному языку, разве что кроме первых пяти.
Человек путается с префиксными и постфиксными операторами? У меня просто нет слов.
Можно избежать большинства заморочек, если не писать как м%дак.
Просто не используйте извращения.
Просто не используйте извращения.
По 7-ому пункту можно добавить уточнение — переопределение параметра не работает, но изменение свойств параметра — очень даже. В вышеприведенном примере можно push-нуть что-то в массив, и это отразится на аргументе.
Логические операторы в вашем примере (16,17) выполняются именно так,
но на самом деле всё определяется приоритетом.
Добавьте пример например
но на самом деле всё определяется приоритетом.
Добавьте пример например
if(ech(1,true) && ech(2,false) || ech(3,false) && ech(4,true) || ech(5,true)) {
console.log('end')
}
// 1
// 2
// 3
// 5
// end
В C вам на такой код выдадут warning. И будут правы: используйте скобки, иначе понять, что здесь происходит, будет сложно. Ещё сложнее будет понять действительно ли вы хотели написать то, что написали, или вы находитесь в заблуждении относительно приоритета.
Или я не нахожусь в заблуждении, а просто понимаю чего хочу от программы.
Но на С — да, пост же о яваскрипте.
Но на С — да, пост же о яваскрипте.
Тот, кто это будет читать, не знает, понимаете ли вы, чего хотите. Скобки (если ими не злоупотребляли) дают наглядное визуальное представление приоритета и показывают, что именно вы хотели от среды исполнения, тогда как при беглом просмотре
То, что данное предупреждение добавили в C, говорит о том, что ошибки, завязанные на непонимании приоритета, слишком часты. Я сильно сомневаюсь, что отсутствие предупреждения могло сделать их более редкими. Отсутствие предупреждения также не могло сделать
Предупреждение, выдаваемое компиляторами, C имеет свои причины. То, что вы пишете не на C, не означает, что в JavaScript эти причины каким‐то магическим образом прекратили своё существование: синтаксис языков при записи комбинаций условных выражений достаточно схож, несмотря на множественные различия вроде результата выполнения
&& и || слабо различимы, требуя более пристального внимания и затрудняя понимание логики при разборе пачки схожих условий.То, что данное предупреждение добавили в C, говорит о том, что ошибки, завязанные на непонимании приоритета, слишком часты. Я сильно сомневаюсь, что отсутствие предупреждения могло сделать их более редкими. Отсутствие предупреждения также не могло сделать
&& и || более различимыми.Предупреждение, выдаваемое компиляторами, C имеет свои причины. То, что вы пишете не на C, не означает, что в JavaScript эти причины каким‐то магическим образом прекратили своё существование: синтаксис языков при записи комбинаций условных выражений достаточно схож, несмотря на множественные различия вроде результата выполнения
&&/||.Тот, кто это будет читать, не знает, понимаете ли вы, чего хотите.
А потом надо использовать не $a+=2 или $a++, а $a=$a+2 и $a=$a+1;
иначе откуда у того, кто будет читать этот код, появится уверенность, что я понимаю, чего хочу?
Предупреждения добавили, молодцы. Но не потому, что так правильно, а потому что одни говнокодеры пишут код, который другие говнокодеры не могут прочитать.
С чем вы будете путать $a++? Здесь нет потенциальной проблемы.
Кроме того, не нужно быть говнокодером, чтобы при чтении цепочки однотипных условий не заметить отличие находящихся между ними операторов. Если вы поставите переносы строк перед/после каждого оператора ИЛИ, то код резко станет более читаемым и без скобок. Но появятся слишком короткие строки и слишком длинное условие. Скобки лучше. Исходный же вариант прямо‐таки создан для запутывания.
Кроме того, не нужно быть говнокодером, чтобы при чтении цепочки однотипных условий не заметить отличие находящихся между ними операторов. Если вы поставите переносы строк перед/после каждого оператора ИЛИ, то код резко станет более читаемым и без скобок. Но появятся слишком короткие строки и слишком длинное условие. Скобки лучше. Исходный же вариант прямо‐таки создан для запутывания.
Капитанство + жуткая каша в голове.
>строгий нуль равен положительному и отрицательному нулям
WAT? Ты вообще слышал что-нибудь про унарные операторы?
Тут такое WAT по половине пунктов :) учи матчасть в общем.
Упс перевод. Тогда все пожелания учить матчасть уходят автору оригинальной статьи :)
>строгий нуль равен положительному и отрицательному нулям
WAT? Ты вообще слышал что-нибудь про унарные операторы?
Тут такое WAT по половине пунктов :) учи матчасть в общем.
Упс перевод. Тогда все пожелания учить матчасть уходят автору оригинальной статьи :)
У меня есть подозрение, что автор перевода недалеко от автора текста ушёл…
WAT? Ты вообще слышал что-нибудь про унарные операторы?
А вы в свою очередь слышали про IEEE754?
Что выдаст
console.log(1/-0)
?
Разъяснения
Вы указали —
Стоит заметить так же —
//к сведению,
console.log([] instanceof Object); //выводит true
Стоит заметить так же —
console.log(new String() instanceof Object); //выводит true
console.log(new Number() instanceof Object); //выводит true
console.log(new Boolean() instanceof Object); //выводит true
console.log(/foo/ instanceof Object); //выводит true
Автор! Марш изучать теорию программирования (и не на js а на статически строго типизированных языках!)
1. Простейшая математика. Не бывает положительного или отрицательного нуля. Он просто нуль!
3. КО: instanceof говорит о классе переменной, примитивы, как и в Java (судя по эффекту) классами не являются.
4. КО: null — действительно Object. Потому что не примитив. Так что это никакая не ошибка. Поизучайте систему классов и примитивов в Java — много параллелей найдёте. Там только ничего подобного typeof нет. Кстати instanceof для null и любого класса должна вернуть false.
6. Повторюсь: теорию марш изучать. При написании метода — параметры. Передаваемые методу — аргументы.
7. Изучаем что такое «передача объекта по ссылке».
16. Опять же: марш изучать!
17. Опять же: марш изучать!
18. Бред. Null — не примитив, а указание пустой ссылки на объект. Вот в таком смысле и использовать. Заменять не инициализированные примитивы им — глупо и неразумно.
20. Любая операция (ваше «выражение») имеет результат (alert(a = 'echo') выбросит окошко с текстом echo), языковые конструкции (if, while, ...) не обязаны иметь результат. Это всё из сей.
21. Да сколько можно капитанить! Марш изучать c/c++/java/…
1. Простейшая математика. Не бывает положительного или отрицательного нуля. Он просто нуль!
3. КО: instanceof говорит о классе переменной, примитивы, как и в Java (судя по эффекту) классами не являются.
4. КО: null — действительно Object. Потому что не примитив. Так что это никакая не ошибка. Поизучайте систему классов и примитивов в Java — много параллелей найдёте. Там только ничего подобного typeof нет. Кстати instanceof для null и любого класса должна вернуть false.
6. Повторюсь: теорию марш изучать. При написании метода — параметры. Передаваемые методу — аргументы.
7. Изучаем что такое «передача объекта по ссылке».
16. Опять же: марш изучать!
17. Опять же: марш изучать!
18. Бред. Null — не примитив, а указание пустой ссылки на объект. Вот в таком смысле и использовать. Заменять не инициализированные примитивы им — глупо и неразумно.
20. Любая операция (ваше «выражение») имеет результат (alert(a = 'echo') выбросит окошко с текстом echo), языковые конструкции (if, while, ...) не обязаны иметь результат. Это всё из сей.
21. Да сколько можно капитанить! Марш изучать c/c++/java/…
>> 1. Простейшая математика. Не бывает положительного или отрицательного нуля. Он просто нуль!
Эм… как раз таки бывает — при вычислении односторонних пределов в окрестности точки разрыва функции, например.
Эм… как раз таки бывает — при вычислении односторонних пределов в окрестности точки разрыва функции, например.
Вы путаете тёплое с мягким.
Когда ищем предел и окрестности — тогда да. А когда значение — тогда нет. Тем и отличается матанализ от математики, что она даёт оценку значения, а не значение.
Согласен, да. Правда, тут вот какая штука:
1/0 === 1/(-0) будет false, но при этом0 === -0 это true. Как мне кажется, суть этого пункта не в наличии в языке +0 и -0, а именно в том, как они сравниваются. Математиков такое поведение может и смутить. Хотя это, пожалуй, копание в мелочах.UFO just landed and posted this here
Или просто используется унарный оператор ± преобразующий к базовому типу(если это возможно), без каких либо положительных или отрицательных нулей. Например:
+ new Date // преобразует в число
+ «123» // аналогично
+true // = 1
-true // = -1
так и
+0 // = 0
-0 // = 0
+ new Date // преобразует в число
+ «123» // аналогично
+true // = 1
-true // = -1
так и
+0 // = 0
-0 // = 0
(Автор, если что, рубист из Польши, судя по подписи в jsFiddle, и Хабр, скорее всего, не читает. Поэтому отвечу на ряд вопросов за него.)
1. Это — претензия к стандарту IEEE 754, которым пользуется масса ЯП. Подробности на SO. Посмотрев, не нашёл способа вытащить знак нуля из переменной (-0). В стандарте, джаве и Си есть CopySign() для этого.
3. Это всё понятно. А теперь представьте, что есть переменная, о которой неизвестно, примитив ли она. Вместо простого instanceof или typeof надо делать продвинутое детектирование типа. На что и ссылается автор.
4. Не будем спорить, посмотрим, что говорит стандарт. Для простоты, смотрим толкование положений 262-3 стандарта словами автора, не вызывающего сомнений: dmitrysoshnikov.com/ecmascript/ru-chapter-7-2-oop-ecmascript-implementation/
6. Ссылка?
7,16,17. Наверное, все знают, но автор пишет, что это ему трудно запомнить.
18. Без комментариев (расскажете автору при встрече).
20. Речь не о том, что не обязаны иметь результат, а о том, что подставить if() на место выражения нельзя (в ряде случаев).
21. Да я сам удивляюсь, но из перевода пункта не выкинешь.
1. Это — претензия к стандарту IEEE 754, которым пользуется масса ЯП. Подробности на SO. Посмотрев, не нашёл способа вытащить знак нуля из переменной (-0). В стандарте, джаве и Си есть CopySign() для этого.
3. Это всё понятно. А теперь представьте, что есть переменная, о которой неизвестно, примитив ли она. Вместо простого instanceof или typeof надо делать продвинутое детектирование типа. На что и ссылается автор.
4. Не будем спорить, посмотрим, что говорит стандарт. Для простоты, смотрим толкование положений 262-3 стандарта словами автора, не вызывающего сомнений: dmitrysoshnikov.com/ecmascript/ru-chapter-7-2-oop-ecmascript-implementation/
Типы примитивных значенийУтверждение о том, что значение типа Null есть примитив, можно увидеть собственными глазами как в 3-й, так и в 5.1-й редакции. ( A primitive value is a member of one of the following built-in types: Undefined, Null, Boolean, Number, and String;)
Возвращаясь к шести типам, используемым ECMAScript программами, первые пять из них: Undefined, Null, Boolean, String и Number — являются типами примитивных значений.
Примеры примитивных значений:
var a = undefined;
var b = null;
var c = true;…
подробности про null
несмотря на то, что тип null‘a, по определению, Null, typeof для этого значения выдаёт «object»:
А дело в том, что оператор typeof возвращает строковое значение, взятое из жёстко закреплённой таблицы, где прописано: “для null – возвращать «object».
Причины этого в стандарте не разъясняются, однако B. Eich (создатель JavaScript) отмечал, что null, в отличии от undefined (который означает неопределённость, “нет значения”), используется в большинстве случаев там, где фигурируют объекты, т.е. является некой сущностью, тесно связанной с объектами (конкретно, означающей нулевую ссылку на объект, “пустышку”, возможно, зарезервировавшую место для будущих целей). Но в некоторых черновиках (например, в невышедшем ECMAScript4 aka JavaScript 2.0) был заведён документ, где данный “феномен” описан как обычный баг. Такое поведение обсуждалось также в одном из баг-трекеров при участии B. Eich’a; в итоге было решено оставить typeof null, как есть (т.е. «object»), хотя сам стандарт ECMA-262-3 описывает тип null-a как Null.
alert(typeof null); // "object"
А дело в том, что оператор typeof возвращает строковое значение, взятое из жёстко закреплённой таблицы, где прописано: “для null – возвращать «object».
Причины этого в стандарте не разъясняются, однако B. Eich (создатель JavaScript) отмечал, что null, в отличии от undefined (который означает неопределённость, “нет значения”), используется в большинстве случаев там, где фигурируют объекты, т.е. является некой сущностью, тесно связанной с объектами (конкретно, означающей нулевую ссылку на объект, “пустышку”, возможно, зарезервировавшую место для будущих целей). Но в некоторых черновиках (например, в невышедшем ECMAScript4 aka JavaScript 2.0) был заведён документ, где данный “феномен” описан как обычный баг. Такое поведение обсуждалось также в одном из баг-трекеров при участии B. Eich’a; в итоге было решено оставить typeof null, как есть (т.е. «object»), хотя сам стандарт ECMA-262-3 описывает тип null-a как Null.
6. Ссылка?
7,16,17. Наверное, все знают, но автор пишет, что это ему трудно запомнить.
18. Без комментариев (расскажете автору при встрече).
20. Речь не о том, что не обязаны иметь результат, а о том, что подставить if() на место выражения нельзя (в ряде случаев).
21. Да я сам удивляюсь, но из перевода пункта не выкинешь.
3. null: null typeof Object && !null instanceof Object
4. Стандарт стандартом а понимание пониманием. По смыслу null — заменитель объекта, значит и примитивом быть не должен. Мне неизвестны компиляторы, которые соответствуют стандарту полностью, если не являются его основой.
6. 90% книг по программированию, которые я читал давали именно такие определения.
20. в большинстве языков таковы правила. Были несогласные — сделали свой блекджек с… сохранением результата выражения у любого выражения.
21. Надо было отметиться, что не согласны с переводимым.
4. Стандарт стандартом а понимание пониманием. По смыслу null — заменитель объекта, значит и примитивом быть не должен. Мне неизвестны компиляторы, которые соответствуют стандарту полностью, если не являются его основой.
6. 90% книг по программированию, которые я читал давали именно такие определения.
20. в большинстве языков таковы правила. Были несогласные — сделали свой блекджек с… сохранением результата выражения у любого выражения.
21. Надо было отметиться, что не согласны с переводимым.
21. C капитанскмми истинами я согласен. Мало ли у кого какие трудности с запоминанием действий операторов. Скорее всего, в Руби порядок операции и взятие значения не меняются местами, а в JS — меняются, и потому для него это было необычным. Вот в 20-м пункте я оставил замечание по странности примера. Но в остальном — всё терпимо — люди разные и не у всех JS — основной язык, чтобы помнить все его тонкости.
Посмотрев, не нашёл способа вытащить знак нуля из переменной (-0)
1/x < 0 ведь ;)переменная, о которой неизвестно, примитив ли она
Это как? О.о Вы не знаете, что храните в собственных переменных?)
4 пункт пофикшен в актуальной версии стандарта.
«О сколько нам открытий чудных» писал классик.
Забыли или надоело писать new — нет проблемы, конструктор вызывается и так
А покажите как вы без new для указанного в статье примера сконструируете объект?
Sign up to leave a comment.
20 и 1 примочка Javascript, которые я никак не могу запомнить