Нет, я говорил о том, что в разных местах разные стили. И как пример, что скопировать из одного места в другое просто так не получится, потому что, как вы сказали,
code style в проекте другой
А потом к моим словам о копировании прицепились (не вы). Может, плохой пример привёл. Я лишь хотел сказать, что code style в проектах настолько разный, что это по сути разные языки.
Предлагаю закрыть тему копипаста )))
Но вот ещё что хочу отметить. Вы использовали шаблоны? типа create-react-app, razzle etc. (к вопросу о чужом коде =) И вот, делаешь проект на подобном шаблоне, ну естественно там eslint prettier и все-все-все. Отдаёшь в руки доблестных солдат фронтенда. Через полгодика приходишь, ёмоё, что за хрень там. А просто задизейблили половину правил eslint по принципу "мне не нравятся ";" в каждой строке и я ниасилил разницу между лямбдой и функцией и всё пишу в функции, или int(``${var}`` + ``${var2}``) потому, что я просто низнаю что там за var и если вдруг не число, то не хочу делать проверку типа."
Чем больше разных возможностей отстрелить себе ногу, тем больше ног будет отстрелено.
Конечно, и на питоне можно завернуть, но всё-таки основные тривиальные случаи PEP8 стандартизирует. И до ревью значительно меньше вывертов доходит. (Хотя да, тоже можно задизейблить, вот только когда есть один стандарт, как-то к нему с большим уважением относятся.)
Я боюсь представить что вы такое разрабатываете, что у вас прокатывает копипаста.
Я боюсь представить, что же за хомпейдж у вас такой, что 99% кода вы самолично напечатали в нём. Для проектов, ведущихся единолично, и в самом деле есть code style, есть clean code нормативы, есть особенности проекта и многое другое, которые кроме вас никому не интересно какие, так как кроме вас в них и нет никого. </sarcasm>
Конечно, сарказм — это лучший способ общения в хабре, доказано поколениями, но он немного мешает вашему собственному пониманию чужих мыслей.
Если в StackOverflow есть ответ на именно чёртову вашу проблему, то почему не скопировать? Зачем менять, если это конкретное решение конкретно в данном месте подходит? Да, это может быть, тот самый случай, случающийся раз в год, но это валидное решение. Вы принципиально будете всё менять? Впрочем, это всё совершенно не имеет никакого отношения к реальной проблеме.
Да, в конце концов, не проблема и поменять. Как я уже сказал, даже вручную может и не надо менять. Вопрос не в том, стоит в каком-то конкретном месте точка с запятой. Вопрос, что если у вас чуть больше чем один ваш хоумпейдж, и в каждой команде свои правила.
Теперь я им объясняю, что можно также использовать глобальный стор, и вот они идут например сюда https://redux-toolkit.js.org/api/createAsyncThunk и берут этот пример. И спрашивают, это точно ЖС? там function, тут const, там ; есть, тут нет ...
код сильно правится под нужды
У кого-то, видимо, со словом "копировать", когда его говорит кто-то другой, стойкая ассоциация "вставить как есть". А на самом деле, просто подумайте, сколько кода вы напечатали на клавиатуре, а сколько вы скопировали, и впоследствии изменили. Любая вещь, которую вы раньше не делали — вы идёте в документацию, и если там есть шаблон, было бы тупо его не скопировать (и изменить), а напечатать всё то же самое пальцами, не так ли? Если вы раньше делали (что-то больше чем пара-тройка строк, в каком-то другом проекте), было бы тупо не скопировать (и естественно изменить).
А теперь представьте, что во всех этих кусках вы правите не только логику, но ещё и синтаксис. Ну хорошо, ; расставит eslint --fix (или prettier). И много чего другого он сумеет. Но кое-что и не сумеет. А кое-где так и вообще сломает (как например function vs () => {} в классах). Так что… Нет, ну если вы не против этим заниматься, пожалуйста. Просто я разрабатываю в другом мире, где почти всех этих проблем нет.
я беру и пишу код, даже не задумываясь где его можно найти и откуда скопировать...
и в результате появляется 100500 тыщ копий одного и того же кода, который вполне бы мог существовать в builtins, только если вы, возможно, человек опытный и можете сразу правильно написать, то сотни джунов пишут всё новые и новые копии с багами.
Что же до сих пор никто не опубликовал его в виде библиотеки?
угу, вот поэтому типичный проект на ноде и устанавливает пару (десятков) тысяч библиотек. Которые ещё и отличаются версиями, потому что какой-то джун изначально написал свою "копию", которая задачу решает либо на 80%, либо просто криво, поэтому кто-то форкнул и теперь их две, и т.п.
То есть те функции по ссылке выше "ломают" сложение массивов?
Вы только буквально умеете понимать?
Для буквоедов объясняю. Меняя какую-то функциональность в языке, которому 30 лет, вы сломаете кучу проектов куче людей. Это очевидно. Рассматривая приведённый пример [] + [] === '', если вы захотите избавиться от данного WTF, то он наверняка сломает кучу проектов, потому что хоть это и выглядит совершенно неразумно, однако же по разным причинам куча кода основана на этом именно в таком виде. И это главная проблема ЖС — любой новый проект на нём, ну просто никак, не может не учитывать ВТФы, которым 30 лет.
Вот как часто вы используете оператор "=="? более того, во всех проектах, которые я видел, есть правило eslint не использовать этот оператор. Ну так уберите его из языка, если с ним столько проблем, в чём проблема? Ведь могли же раньше "use strict", придумайте что-нибуть аналогичное питоновскому, условно
from __future__ import double_equals_is_strict_equals
и можно будет писать а == б вместо а === б. (Опять же, это пример.)
Но нет, зато вот мы введём какой-то мутный private, который 80% разработчикам за всю жизнь не пригодится ни разу. И сделаем его через Ж #, потому что "совместимость" же.
Когда я смотрю на сайт https://node.green, думаю — о, вот круто, столько всего понафигачили, аж 5 минут грузится. А ведь на самом деле за этим нафигачением стоит лишь одно — бардак. Здесь покосилось — гвоздь забили. Там покосилось — костыль забили. Всё здание ЖС держится пока на трёх костылях — основа языка 30-летней давности, огромная распространённость в вебе и, надо отдать должное, инфраструктура, одна из самых развитых (отчасти и в силу того, что нода не так давно набрала популярность и пользуется современными достижениями — гитхаб, репозитории пакетов и тп. постольку, поскольку этот путь уже был пройден другими ранее). Но я хорошо помню, как больше 10 лет назад на Опеннете, в треде про РНР, я писал — ребята, бросьте вы это фуфло, переходите на ЖС в качестве бэкенда. И мне отвечали: да ты сумасшедший! РНР классный язык, бла бла бла! но… через полгода гугл объявил о том, что V8 будет использоваться для консольного скриптинга.
И где теперь РНР? Удел маргиналов (слегка утрируя, конечно). Хотя в последнее время довольно неплохо развивается… Я впрочем не хочу делать прогнозы. К тому же, я прекрасно понимаю, что человек, всю жизнь пишущий на ЖС, просто не думает об этих проблемах, воспринимая их как данность. Но всё познаётся в сравнении.
Дык кто спорит, что это можно. А вот чтобы к примеру найти общие элементы двух массивов:
common = set(list1).intersection(list2)
Это на питоне, а попробуйте на ЖС написать. А, ну да — идёте в https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set#Implementing_basic_set_operations и копируете. И кто там — mayorovp — упрекал меня в копировании из доков. А что ещё делать остаётся-то. И вот все копируют, копируют, копируют… Все проекты начинаются с кучи бойлерплейта, который давно пора уже занести в язык, но не можно потому, что иначе ваше [] + [] === '' — ключевая фича ЖСа 30-летней давности — не будет работать.
Да, вы правы, я в курсе, зачем нужен сеттер, просто не понял, что вы имеете в виду нежелательный вызов сеттера в случае того самого "лишнего" присваивания. Я подумал, вы о том, что разница в вызове сеттеров зависит от оператора.
ОМГ, ещё один ВТФ. Т.е. при одном присваивании сеттер вызывается, при другом — нет?
Автор предложения занимается этим на общественных началах
да у меня к автору предложения нет претензий. У меня вообще нет претензий. Я просто констатирую факт, что язык, который и так чемпион по ВТФам, вместо того, чтобы с ними разбираться, делают ещё более запутанным.
Я преподаю на курсах веб-программирования, и знаете ли, в разделе про ЖС 80% времени приходится объяснять людям, что операторы в ЖС далеко не всегда делают то, что от них ожидаешь. Особенно после питона.
Да, оно не мешает, но когда у вас 30 лет назад был запорожец и вы по одной запчасти меняете то от мерседеса, то от лексуса, то от велосипеда...
копируете примеры из доков без исправления?
и что ужасного? Если мне (или моим студентам) нужно быстро создать какой-нибудь нечасто используемый реакт хук или даже простую форму с формиком, то что, по-вашему, вы всё это пишете ручками с нуля? Не врите хоть самому себе.
Конечно использовать пример один к одному не получится, но править в них синтаксис (в добавок к логике) занятие то ещё.
Хмм. Язык, в котором кругом одни несогласованности, вдруг задумался о согласованности оператора, существовавшего 30 лет ??=))
Когда я смотрю проекты, делаемые разными командами, ощущение такое, что у каждой свой ЖС. У одних ;, у других нет. У одних const f = (a) => a, у других function f(a) { return a} и т.д. и т.п.
Даже банально примеры из доков библиотек в проект не вставить без того, чтобы ручками половину править, чтоб eslint не обгадил.
С этим бы лучше разбирались.
Ладно. Не моё дело. Зато я счастлив, что мне не приходится писать на ноде каждый день. ||=))
Да, спасибо, я тоже уже осознал, что "лишнее" имеется в виду "всегда" (в противовес только "в случае, если х не фолси") :)
Хотя конечно в современных реалиях напугать кого-то лишним присваиванием думаю не получится. Когда пишешь React, то твой собственный код часто вообще на производительность никак не влияет =) можно хоть биткойны майнить, всё равно хуже не будет.
Как по мне, лучше бы господа ЖСники подумали о том, как разобраться с WTFами, прежде чем микросахаром заниматься. Хотя, с другой стороны, проще просто взять другой язык. Вон уже и на питоне можно писать для веба.
А как RFC должно с этим помогать?
Например вот так:
… какое конкретно поле имеет недопустимое значение
Так что, на каждый заголовок и каждое поле свой код ошибки?
ошибка 401 Unauthorized: по спецификации она обязана сопровождаться заголовком WWW-Authenticate — чего, в реальности, конечно никто не делает
Да, соглашусь, что в данном случае спецификация, требующая какой-то конкретной схемы авторизации, и не учитывающая их разнообразия, устарела и является проблемой. Но если всё прекрасно работает и без этой спецификации, пожалуй можно в данном случае ей не следовать, либо быть пуристом и использовать 403.
На прочие ваши вопросы также есть ответы в тексте.
Вы про "А какие ваши предложения?" Ну там особо ответов то и нет, а) не использовать вообще б) оставить всё как есть в) "прибрать бардак" — полностью переделать протокол???
Тем не менее, в HTTP полно ошибок на невалидное значение одного конкретного параметра запроса
Некоторые коды присутствуют совершенно обоснованно, если показывают не "параметр запроса", а валидность самого запроса. Можно конечно спорить, но длина payload / URI не является параметром запроса, как и метод. Например, заголовок Expect является критичным в конкретном случае и тоже обоснованно имеет соответствующий код ошибки 417. Хотя в данном случае, возможно, не самое оптимальное решение вообще инициировать protocol switch используя заголовок.
Но по крайней мере это всё однозначно определяет действия клиента — как раз то, ради чего вы эту статью писали. Чётко понятно, что не так в данном запросе. При длине payload, регулярно вываливающейся за пределы, может быть отрегулируем client_max_body_size или что-то ещё. При длине URI — может у нас в приложении урлы некорректно генерируются (впрочем, обоснованность ограничения длины URI тоже сомнения вызывает, если на то пошло). Не тот метод? Тоже повод проверить приложение.
Теперь представим, что на каждый header свой код ошибки — и что вы с этим будете делать? Как это вам поможет, если скажем, тот же Accept не имеет чёткого множества допустимых параметров? Вы будете это вообще использовать в вашем приложении? Вам нужен график, сколько запросов с неправильным Accept header?
Как я уже сказал, для концепции REST в принципе числовые коды ошибок не нужны. Всё можно впихнуть в 500 или в 200, лишь бы было соответствующее сообщение, а разграничения по кодам нужны только для удобства настройки софта, типа nginx, который задизайнен (в теории) в соответствии со спецификациями. То, что вы будете использовать статус 200 для всех респонсов, не сделает ваши приложения не-REST, просто оно усложнит работу с ними. Но идти в другую крайность и кидать новый числовой код ошибки для каждой новой ситуации — это ещё более бредово, учитывая, что числовой код вообще штука крайне неудобная и сама по себе легаси. Если бы протокол НТТР разрабатывался в наше время, я уверен, не было бы никаких чисел, а было бы что-то вроде
[INFO] Continue
[OK] OK / Created / Accepted ...
[REDIRECT] ...
...
С этим гораздо проще и нагляднее работать, и не нужно заморочек с мапингом этого всего туда-сюда.
С другой стороны, мы, можно сказать, уже потеряли возможность писать НТТР-запросы вручную, в связи с массовым приходом SSL, и сейчас все эти текстовые поля скорее существуют в нашем воображении, и не исключено, что в НТТР/3 будет принципиально другой подход, например, непосредственная двоичная кодировка. Реальность уже далеко ушла от названия Hypertext Transfer, а что будет дальше, предсказать вообще сложно.
Так что если вы хотели сказать, что НТТР не идеален, то согласен — не идеален. Следует ли из этого, что нужно заморачиваться с улучшением кодов ошибок в спецификации? Думаю нет. Просто вы опоздали на пару десятков лет :)
Но вот с чем RFC совершенно не помогает — это с вопросом, а что собственно клиенту или прокси делать с ошибкой.
А как RFC должно с этим помогать? Действия клиента зависят от приложения. Нет универсального клиента.
статус-коды HTTP используются вовсе не в целях поддержания чистоты протокола
Какого именно протокола? Если кто-то конкретный использует HTTP статусы не по назначению, это не значит, что статусы плохие. HTTP-протокол для приложений не более чем транспорт, и любое приложение определяет свой собственный протокол поверх HTTP.
нельзя задизайнить по ошибке на каждый потенциально неправильный параметр вместо единой 400-ки,
… противоречит парадигме REST
В чём противоречие? Откуда возникла мысль, что REST как-то связан с кодом ошибки? Вполне достаточно 1 кода на все ошибки, с точки зрения парадигмы REST.
графики и мониторинги
И их можно настроить, тот же ELK стек не только на коды ошибок смотрит, но и на содержание месседжа. Да, это требует доп. усилий, но всё в этом мире требует усилий. Я не представляю, если бы на каждую ошибку в НТТР-заголовке был бы свой код ошибки — был бы вообще протокол НТТР юзабелен сколь-нибудь.
Как по мне, эта проблема сильно надумана и вкратце статью можно выразить фразой "есть люди, которые не умеют НТТР" (имея в виду, в том числе и тех, кто не знает, какие статусы кешируются по умолчанию).
нативный assert — это самое крутое, что можно использовать для тестов. Все эти self.assertEqual, mock.assertCalled и т.п. — это всё костыли, которые скрывают самое главное, тот expression, что вы тестируете. Когда вы берёте конфету, какой бы ни был красивый фантик, всё-таки он вторичен.
Если первый ассерт упал, то с вероятностью 1/2 — 1 остальные проверки бессмысленны, потому что по-хорошему тест должен быть составлен так, что тестирует зависимые друг от друга вещи. Если две проверки в тесте независимы, это лучше оформить как 2 разных теста, так как имя, данное тесту, это половина (не)понимания того, почему он упал.
Нативный вывод pytest гораздо лучше выглядит, подсветка и всё такое.
Бритва Оккама — лишние сущности не нужны.
Чем проще тест (и не только), чем меньше всяких обёрток, фантиков, тем быстрее, проще, дешевле, приятнее разработка.
Своими ручками можно что угодно наваять, но зачем внедрять в язык всякие синтаксические конструкции, которые ни разу не упрощают жизнь, вместо нормального API для соответствующих объектов-типов-классов.
Вот добавили Set, ну и что? Совершенно непонятно, как его использовать без дюжины дополнительных функций, таких как union, difference, intersection… почему не добавить их сразу в АПИ класса Set? Нет, нужно больше модулей npm видимо… Я бы на месте разработчиков этих стандартов первое что сделал, это затащил в стандарт lodash API, хотя бы процентов этак 90. Это было бы намного полезнее, чем изобретать ещё один велосипед для решения проблемы, которую решают созданием новой проблемы.
Нет, я говорил о том, что в разных местах разные стили. И как пример, что скопировать из одного места в другое просто так не получится, потому что, как вы сказали,
А потом к моим словам о копировании прицепились (не вы). Может, плохой пример привёл. Я лишь хотел сказать, что code style в проектах настолько разный, что это по сути разные языки.
Предлагаю закрыть тему копипаста )))
Но вот ещё что хочу отметить. Вы использовали шаблоны? типа create-react-app, razzle etc. (к вопросу о чужом коде =) И вот, делаешь проект на подобном шаблоне, ну естественно там eslint prettier и все-все-все. Отдаёшь в руки доблестных солдат фронтенда. Через полгодика приходишь, ёмоё, что за хрень там. А просто задизейблили половину правил eslint по принципу "мне не нравятся ";" в каждой строке и я ниасилил разницу между лямбдой и функцией и всё пишу в функции, или
int(``${var}`` + ``${var2}``)потому, что я просто низнаю что там за var и если вдруг не число, то не хочу делать проверку типа."Чем больше разных возможностей отстрелить себе ногу, тем больше ног будет отстрелено.
Конечно, и на питоне можно завернуть, но всё-таки основные тривиальные случаи PEP8 стандартизирует. И до ревью значительно меньше вывертов доходит. (Хотя да, тоже можно задизейблить, вот только когда есть один стандарт, как-то к нему с большим уважением относятся.)
Я боюсь представить, что же за хомпейдж у вас такой, что 99% кода вы самолично напечатали в нём. Для проектов, ведущихся единолично, и в самом деле есть code style, есть clean code нормативы, есть особенности проекта и многое другое, которые кроме вас никому не интересно какие, так как кроме вас в них и нет никого.
</sarcasm>Конечно, сарказм — это лучший способ общения в хабре, доказано поколениями, но он немного мешает вашему собственному пониманию чужих мыслей.
Если в StackOverflow есть ответ на именно чёртову вашу проблему, то почему не скопировать? Зачем менять, если это конкретное решение конкретно в данном месте подходит? Да, это может быть, тот самый случай, случающийся раз в год, но это валидное решение. Вы принципиально будете всё менять? Впрочем, это всё совершенно не имеет никакого отношения к реальной проблеме.
Да, в конце концов, не проблема и поменять. Как я уже сказал, даже вручную может и не надо менять. Вопрос не в том, стоит в каком-то конкретном месте точка с запятой. Вопрос, что если у вас чуть больше чем один ваш хоумпейдж, и в каждой команде свои правила.
Вы правы. Кто спорит. Но мне вот нравится поныть о недостатках ЖС =) имею право? ??=))
чем, если не секрет. Мне вот он тоже не нравился 10 лет назад. Просто не приходилось использовать.
Хоть и не вам комментарий был адресован :) но вы сами и признали, что копируете.
Да, всё так.
Типичная для меня ситуация. При работе со студентами, скажем я даю задание использовать реакт хук useCallback, и вот они логично берут этот пример: https://reactjs.org/docs/hooks-reference.html#usecallback
Теперь я им объясняю, что можно также использовать глобальный стор, и вот они идут например сюда https://redux-toolkit.js.org/api/createAsyncThunk и берут этот пример. И спрашивают, это точно ЖС? там
function, тутconst, там;есть, тут нет ...У кого-то, видимо, со словом "копировать", когда его говорит кто-то другой, стойкая ассоциация "вставить как есть". А на самом деле, просто подумайте, сколько кода вы напечатали на клавиатуре, а сколько вы скопировали, и впоследствии изменили. Любая вещь, которую вы раньше не делали — вы идёте в документацию, и если там есть шаблон, было бы тупо его не скопировать (и изменить), а напечатать всё то же самое пальцами, не так ли? Если вы раньше делали (что-то больше чем пара-тройка строк, в каком-то другом проекте), было бы тупо не скопировать (и естественно изменить).
А теперь представьте, что во всех этих кусках вы правите не только логику, но ещё и синтаксис. Ну хорошо,
;расставит eslint --fix (или prettier). И много чего другого он сумеет. Но кое-что и не сумеет. А кое-где так и вообще сломает (как напримерfunctionvs() => {}в классах). Так что… Нет, ну если вы не против этим заниматься, пожалуйста. Просто я разрабатываю в другом мире, где почти всех этих проблем нет.и в результате появляется 100500 тыщ копий одного и того же кода, который вполне бы мог существовать в builtins, только если вы, возможно, человек опытный и можете сразу правильно написать, то сотни джунов пишут всё новые и новые копии с багами.
угу, вот поэтому типичный проект на ноде и устанавливает пару (десятков) тысяч библиотек. Которые ещё и отличаются версиями, потому что какой-то джун изначально написал свою "копию", которая задачу решает либо на 80%, либо просто криво, поэтому кто-то форкнул и теперь их две, и т.п.
Вы только буквально умеете понимать?
Для буквоедов объясняю. Меняя какую-то функциональность в языке, которому 30 лет, вы сломаете кучу проектов куче людей. Это очевидно. Рассматривая приведённый пример
[] + [] === '', если вы захотите избавиться от данного WTF, то он наверняка сломает кучу проектов, потому что хоть это и выглядит совершенно неразумно, однако же по разным причинам куча кода основана на этом именно в таком виде. И это главная проблема ЖС — любой новый проект на нём, ну просто никак, не может не учитывать ВТФы, которым 30 лет.Вот как часто вы используете оператор "=="? более того, во всех проектах, которые я видел, есть правило eslint не использовать этот оператор. Ну так уберите его из языка, если с ним столько проблем, в чём проблема? Ведь могли же раньше "use strict", придумайте что-нибуть аналогичное питоновскому, условно
и можно будет писать а == б вместо а === б. (Опять же, это пример.)
Но нет, зато вот мы введём какой-то мутный private, который 80% разработчикам за всю жизнь не пригодится ни разу. И сделаем его через
Ж#, потому что "совместимость" же.Когда я смотрю на сайт https://node.green, думаю — о, вот круто, столько всего понафигачили, аж 5 минут грузится. А ведь на самом деле за этим нафигачением стоит лишь одно — бардак. Здесь покосилось — гвоздь забили. Там покосилось — костыль забили. Всё здание ЖС держится пока на трёх костылях — основа языка 30-летней давности, огромная распространённость в вебе и, надо отдать должное, инфраструктура, одна из самых развитых (отчасти и в силу того, что нода не так давно набрала популярность и пользуется современными достижениями — гитхаб, репозитории пакетов и тп. постольку, поскольку этот путь уже был пройден другими ранее). Но я хорошо помню, как больше 10 лет назад на Опеннете, в треде про РНР, я писал — ребята, бросьте вы это фуфло, переходите на ЖС в качестве бэкенда. И мне отвечали: да ты сумасшедший! РНР классный язык, бла бла бла! но… через полгода гугл объявил о том, что V8 будет использоваться для консольного скриптинга.
И где теперь РНР? Удел маргиналов (слегка утрируя, конечно). Хотя в последнее время довольно неплохо развивается… Я впрочем не хочу делать прогнозы. К тому же, я прекрасно понимаю, что человек, всю жизнь пишущий на ЖС, просто не думает об этих проблемах, воспринимая их как данность. Но всё познаётся в сравнении.
Дык кто спорит, что это можно. А вот чтобы к примеру найти общие элементы двух массивов:
Это на питоне, а попробуйте на ЖС написать. А, ну да — идёте в https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set#Implementing_basic_set_operations и копируете. И кто там — mayorovp — упрекал меня в копировании из доков. А что ещё делать остаётся-то. И вот все копируют, копируют, копируют… Все проекты начинаются с кучи бойлерплейта, который давно пора уже занести в язык, но не можно потому, что иначе ваше
[] + [] === ''— ключевая фича ЖСа 30-летней давности — не будет работать.Да, вы правы, я в курсе, зачем нужен сеттер, просто не понял, что вы имеете в виду нежелательный вызов сеттера в случае того самого "лишнего" присваивания. Я подумал, вы о том, что разница в вызове сеттеров зависит от оператора.
ОМГ, ещё один ВТФ. Т.е. при одном присваивании сеттер вызывается, при другом — нет?
да у меня к автору предложения нет претензий. У меня вообще нет претензий. Я просто констатирую факт, что язык, который и так чемпион по ВТФам, вместо того, чтобы с ними разбираться, делают ещё более запутанным.
Я преподаю на курсах веб-программирования, и знаете ли, в разделе про ЖС 80% времени приходится объяснять людям, что операторы в ЖС далеко не всегда делают то, что от них ожидаешь. Особенно после питона.
Да, оно не мешает, но когда у вас 30 лет назад был запорожец и вы по одной запчасти меняете то от мерседеса, то от лексуса, то от велосипеда...
и что ужасного? Если мне (или моим студентам) нужно быстро создать какой-нибудь нечасто используемый реакт хук или даже простую форму с формиком, то что, по-вашему, вы всё это пишете ручками с нуля? Не врите хоть самому себе.
Конечно использовать пример один к одному не получится, но править в них синтаксис (в добавок к логике) занятие то ещё.
Хмм. Язык, в котором кругом одни несогласованности, вдруг задумался о согласованности оператора, существовавшего 30 лет ??=))
Когда я смотрю проекты, делаемые разными командами, ощущение такое, что у каждой свой ЖС. У одних
;, у других нет. У однихconst f = (a) => a, у другихfunction f(a) { return a}и т.д. и т.п.Даже банально примеры из доков библиотек в проект не вставить без того, чтобы ручками половину править, чтоб eslint не обгадил.
С этим бы лучше разбирались.
Ладно. Не моё дело. Зато я счастлив, что мне не приходится писать на ноде каждый день. ||=))
Да, спасибо, я тоже уже осознал, что "лишнее" имеется в виду "всегда" (в противовес только "в случае, если х не фолси") :)
Хотя конечно в современных реалиях напугать кого-то лишним присваиванием думаю не получится. Когда пишешь React, то твой собственный код часто вообще на производительность никак не влияет =) можно хоть биткойны майнить, всё равно хуже не будет.
Как по мне, лучше бы господа ЖСники подумали о том, как разобраться с WTFами, прежде чем микросахаром заниматься. Хотя, с другой стороны, проще просто взять другой язык. Вон уже и на питоне можно писать для веба.
Эквивалентный код для
-
(видимо опечатка у вас,
!там явно лишний).И ради таких крайних случаев вводить новый оператор, да. То есть, целых три. Старый добрый if видимо скоро вообще станет ненужным ??=)))
Язык с самым большим числом WTF и способов отстрелить себе ногу станет ещё разнообразнее.
Да, точно. Спасибо за коммент. Я мыслил в правильном направлении =)
Цитируя себя:
s/3/2/
s/будет//
:)
Так что, на каждый заголовок и каждое поле свой код ошибки?
Да, соглашусь, что в данном случае спецификация, требующая какой-то конкретной схемы авторизации, и не учитывающая их разнообразия, устарела и является проблемой. Но если всё прекрасно работает и без этой спецификации, пожалуй можно в данном случае ей не следовать, либо быть пуристом и использовать 403.
Вы про "А какие ваши предложения?" Ну там особо ответов то и нет, а) не использовать вообще б) оставить всё как есть в) "прибрать бардак" — полностью переделать протокол???
Некоторые коды присутствуют совершенно обоснованно, если показывают не "параметр запроса", а валидность самого запроса. Можно конечно спорить, но длина payload / URI не является параметром запроса, как и метод. Например, заголовок
Expectявляется критичным в конкретном случае и тоже обоснованно имеет соответствующий код ошибки 417. Хотя в данном случае, возможно, не самое оптимальное решение вообще инициировать protocol switch используя заголовок.Но по крайней мере это всё однозначно определяет действия клиента — как раз то, ради чего вы эту статью писали. Чётко понятно, что не так в данном запросе. При длине payload, регулярно вываливающейся за пределы, может быть отрегулируем
client_max_body_sizeили что-то ещё. При длине URI — может у нас в приложении урлы некорректно генерируются (впрочем, обоснованность ограничения длины URI тоже сомнения вызывает, если на то пошло). Не тот метод? Тоже повод проверить приложение.Теперь представим, что на каждый header свой код ошибки — и что вы с этим будете делать? Как это вам поможет, если скажем, тот же Accept не имеет чёткого множества допустимых параметров? Вы будете это вообще использовать в вашем приложении? Вам нужен график, сколько запросов с неправильным Accept header?
Как я уже сказал, для концепции REST в принципе числовые коды ошибок не нужны. Всё можно впихнуть в 500 или в 200, лишь бы было соответствующее сообщение, а разграничения по кодам нужны только для удобства настройки софта, типа nginx, который задизайнен (в теории) в соответствии со спецификациями. То, что вы будете использовать статус 200 для всех респонсов, не сделает ваши приложения не-REST, просто оно усложнит работу с ними. Но идти в другую крайность и кидать новый числовой код ошибки для каждой новой ситуации — это ещё более бредово, учитывая, что числовой код вообще штука крайне неудобная и сама по себе легаси. Если бы протокол НТТР разрабатывался в наше время, я уверен, не было бы никаких чисел, а было бы что-то вроде
С этим гораздо проще и нагляднее работать, и не нужно заморочек с мапингом этого всего туда-сюда.
С другой стороны, мы, можно сказать, уже потеряли возможность писать НТТР-запросы вручную, в связи с массовым приходом SSL, и сейчас все эти текстовые поля скорее существуют в нашем воображении, и не исключено, что в НТТР/3 будет принципиально другой подход, например, непосредственная двоичная кодировка. Реальность уже далеко ушла от названия Hypertext Transfer, а что будет дальше, предсказать вообще сложно.
Так что если вы хотели сказать, что НТТР не идеален, то согласен — не идеален. Следует ли из этого, что нужно заморачиваться с улучшением кодов ошибок в спецификации? Думаю нет. Просто вы опоздали на пару десятков лет :)
(пардон не тот тред)
Не понял, в чём проблема HTTP статус-кодов.
А как RFC должно с этим помогать? Действия клиента зависят от приложения. Нет универсального клиента.
Какого именно протокола? Если кто-то конкретный использует HTTP статусы не по назначению, это не значит, что статусы плохие. HTTP-протокол для приложений не более чем транспорт, и любое приложение определяет свой собственный протокол поверх HTTP.
В чём противоречие? Откуда возникла мысль, что REST как-то связан с кодом ошибки? Вполне достаточно 1 кода на все ошибки, с точки зрения парадигмы REST.
И их можно настроить, тот же ELK стек не только на коды ошибок смотрит, но и на содержание месседжа. Да, это требует доп. усилий, но всё в этом мире требует усилий. Я не представляю, если бы на каждую ошибку в НТТР-заголовке был бы свой код ошибки — был бы вообще протокол НТТР юзабелен сколь-нибудь.
Как по мне, эта проблема сильно надумана и вкратце статью можно выразить фразой "есть люди, которые не умеют НТТР" (имея в виду, в том числе и тех, кто не знает, какие статусы кешируются по умолчанию).
Как по мне, так это наоборот какой-то костыль.
Чем проще тест (и не только), чем меньше всяких обёрток, фантиков, тем быстрее, проще, дешевле, приятнее разработка.
так речь о том, чтобы это было в языке.
Своими ручками можно что угодно наваять, но зачем внедрять в язык всякие синтаксические конструкции, которые ни разу не упрощают жизнь, вместо нормального API для соответствующих объектов-типов-классов.
Вот добавили Set, ну и что? Совершенно непонятно, как его использовать без дюжины дополнительных функций, таких как union, difference, intersection… почему не добавить их сразу в АПИ класса Set? Нет, нужно больше модулей npm видимо… Я бы на месте разработчиков этих стандартов первое что сделал, это затащил в стандарт lodash API, хотя бы процентов этак 90. Это было бы намного полезнее, чем изобретать ещё один велосипед для решения проблемы, которую решают созданием новой проблемы.
И кому это нужно?
для этого случая лучше бы занесли setdefault как в питоне:
Чувствую скоро JS скатится в что-то подобное ICQ для 12-летних