Да, это кажется странным на первый взгляд, но на самом деле все довольно просто.
Интерфейс метода описывает максимальное допустимое множество значений, которые может обработать.
Имплементация может расширить это множество, скажем обрабатывать не только int, но еще и long, — это не сломает интерфейс int это подмножество множества long. А вот вместо int принимать short мы уже не сможем, т.к. множество short меньше множества int.
— а если работать через интерфейс, то сам интерфейс не позволит передать long, даже если в имплементации аргумент типа long.
Примерно такой же подход при возврате значения, мы можем Уменьшать множество ответов, но не можем его расширять. Уменьшать мы можем только, если меньшее множество ответов является подмножеством большего.
К примеру long в интерфейсе мы сможем заменить на int в имплементации, но вот заменить на bool — не сможем, bool — не является подмножеством множества long. (под bool подразумевается множество {true, false}, а не {1,0})
ps: примеры long, int, bool приведены как ограниченные множества, чтобы проще было понять идею, в реальности такие манипуляции могут не пройти.
Если работать через интерфейс, то более строгая имплементация ничего не поменяет. При этом, более строгая имплементация, сама по себе, запрещает коду сделать что-то не так.
Эта фича в простом коде не будет сильно использоваться, но дает гибкость для построения абстракции (при разработке фреймворков и библиотек).
Можно предположить, что это сделано для обратной совместимости.
Код, который имеет такое поведение уже написан и просто так ломать его не принесет успеха новой версии языка.
Хотя с другой стороны, было бы не плохо кидать какой-то warning для такого кода, чтобы фиксили активнее.
Кажется вы не к тому комменту ответили. Ваши слова лишь подтверждают мои.
Моя позиция в том, что для сохранения referer нужно делать 3xx редирект html контента.
В сообщениях выше по этой ветке коллеги предлагают отдать контент и уже из контента делать редирект. Отдать html контент с 404 кодом, даже если и получится, то это не правильно.
И если таки отдать 404.html — то при редиректе с нее в реферер будет установлен 404.html, а не ресурс, с которого пришли.
> А зачем делать редирект на 404.html, когда можно просто отдать код страницы?
Спасибо, интересный вариант, про него не подумал про него!
Но есть 2 «но»:
1. Отдав контент и далее сделав редирект — Referer у редиректа будет запрошенная страница (которой нету).
2. Этот вариант займет больше времени. Сначала нужно доставить контент (объем больше, чем у пустого редиректа), потом нужно будет этот контент отрендерить, и лишь потом будет выполнен редирект.
> Для этого существует тэг noscript.
— пользователь пришел на 404.html и ушел, это не то, что он ожидал увидеть и ничего, что привлекло бы его внимание тут нету. пользователь ушел.
серверный редирект позволит сразу его перекинуть на хомпейдж, и там уже есть вероятность, что он задержится дольше, чем на 404.html
А решение проблемы с /favicon очень простое — нужно правильно настроить рулы редиректа. Для всех картинок прописать 404, без редиректа, а для 404 при запросе html — прописать редирект на хомпейдж. Велосипедов придумывать не нужно, все уже давно известно.
> Это случится, если при некорректном запросе сначала делать редирект на страницу 404, а не отдавать код сразу.
сценарий:
— пользователь из внешнего источника «А» тыкает на ссылку, которая ведет на отсутствующую страницу (почему отсутствует — другой вопрос).
страницы нету — он попадает на 404.html, на которой стоит редирект на хомпейдж. перейдя на хомпейдж — у него в referer будет 404.html, а не «ресурс А»
единственный способ сохранить referer — серверный редирект.
Но вот есть множество проектов, которые сделаны на столько коряво, что и на /favicon отдается 404.html и даже на ошибочный рест запрос тоже 404.html словить можно.
Иногда js в браузере может быть выключен и иногда все же есть требования, чтобы сайты работали без js. Да, это не можно, не круто, но иногда бизнесу так выгоднее. А соответственно js редирект не будет работать.
А еще есть прикол с Referer при редиректе через js (иногда это тоже важно). При серверном редиректе referer нового запроса будет первоначальная страница, а при js редиректе — текущая страница.
Во-первых, есть кейс, когда пользователя с 404 лучше отправить на home page, чтобы он не ушел. Во-вторых, иногда даже 404 страница должна быть не просто статикой (редко, но бывает).
В результате любой 404 может превратиться в нагрузку на сервер.
Проблема для продакшена не частая — почти любой сайт имеет favicon, но тем не менее.
У них в синтаксисе короткие слова, которые с табами в 4 символа хорошо сочетаются (ну и форматер стандартный, но как видно по гитхабу, не все его используют).
Возможно мы друг друга не поняли. Я подразумевал настройку замены пробелами при нажатии на клавишу табуляции. При нажатии на клавишу вставляется на 1 символ табуляции, а 2-4-8 пробелов, в зависимости от того, где сейчас стоит каретка (Таб по своей семантике может занимать место в N знаков).
Но в указанном примере есть проблема: в настройках стоит 8 знаков на 1 таб, если было бы 4 — было бы красивее.
Обычно табы в 4 символа хорошо сочетаются с языками в которых короткие ключевые слова: def, var, let, val; потому их там и любят применять.
> При настроенном табе в 2 или 8 символов (а это ведь один из основных доводов) получается такая каша
Смотря какой тул использовать. Если использовать качественный — то все будет нормально выравниваться, если в простом блокноте работать — да, будет не удобно.
В IDE тоже желательно использовать настройки проекта или хотя бы придерживаться тех отступов, которые у тебя в текущем файле, я бы даже сказал, в текущей функции / методе. Не редко бывают проекты, где часть кода с пробелами, а часть с табами. Более того, иногда в одной строке могут быть как пробелы, так и табы :(
Эти люди не хотят по-другому, они не используют все преимущества, которые им предоставляют всевозможные тулы. Есть исключения (нету редактора), но это редкость.
зы: я уже и забыл, когда сам делал отступы в коде.
Всякий раз, когда правительство вмешивается в Интернеты под видом «мы хотим помочь своим гражданам», от этого страдают именно конечные пользователи, которым пытались помочь.
> Какие извращения? И в чём проблема с поспеванием? Из GWT можно отлично вызывать любой JS-код, самый новомодный и хипстерский.
Вот тут то и будет извращение. Вместо того, чтобы просто писать на js, часть логики будет на java(gwt), а часть на js. И в этом случае все так же придется переключаться между java и js.
Интерфейс метода описывает максимальное допустимое множество значений, которые может обработать.
Имплементация может расширить это множество, скажем обрабатывать не только int, но еще и long, — это не сломает интерфейс int это подмножество множества long. А вот вместо int принимать short мы уже не сможем, т.к. множество short меньше множества int.
— а если работать через интерфейс, то сам интерфейс не позволит передать long, даже если в имплементации аргумент типа long.
Примерно такой же подход при возврате значения, мы можем Уменьшать множество ответов, но не можем его расширять. Уменьшать мы можем только, если меньшее множество ответов является подмножеством большего.
К примеру long в интерфейсе мы сможем заменить на int в имплементации, но вот заменить на bool — не сможем, bool — не является подмножеством множества long. (под bool подразумевается множество {true, false}, а не {1,0})
ps: примеры long, int, bool приведены как ограниченные множества, чтобы проще было понять идею, в реальности такие манипуляции могут не пройти.
Эта фича в простом коде не будет сильно использоваться, но дает гибкость для построения абстракции (при разработке фреймворков и библиотек).
Код, который имеет такое поведение уже написан и просто так ломать его не принесет успеха новой версии языка.
Хотя с другой стороны, было бы не плохо кидать какой-то warning для такого кода, чтобы фиксили активнее.
Моя позиция в том, что для сохранения referer нужно делать 3xx редирект html контента.
В сообщениях выше по этой ветке коллеги предлагают отдать контент и уже из контента делать редирект. Отдать html контент с 404 кодом, даже если и получится, то это не правильно.
И если таки отдать 404.html — то при редиректе с нее в реферер будет установлен 404.html, а не ресурс, с которого пришли.
Спасибо, интересный вариант, про него не подумал про него!
Но есть 2 «но»:
1. Отдав контент и далее сделав редирект — Referer у редиректа будет запрошенная страница (которой нету).
2. Этот вариант займет больше времени. Сначала нужно доставить контент (объем больше, чем у пустого редиректа), потом нужно будет этот контент отрендерить, и лишь потом будет выполнен редирект.
— пользователь пришел на 404.html и ушел, это не то, что он ожидал увидеть и ничего, что привлекло бы его внимание тут нету. пользователь ушел.
серверный редирект позволит сразу его перекинуть на хомпейдж, и там уже есть вероятность, что он задержится дольше, чем на 404.html
А решение проблемы с /favicon очень простое — нужно правильно настроить рулы редиректа. Для всех картинок прописать 404, без редиректа, а для 404 при запросе html — прописать редирект на хомпейдж. Велосипедов придумывать не нужно, все уже давно известно.
> Это случится, если при некорректном запросе сначала делать редирект на страницу 404, а не отдавать код сразу.
сценарий:
— пользователь из внешнего источника «А» тыкает на ссылку, которая ведет на отсутствующую страницу (почему отсутствует — другой вопрос).
страницы нету — он попадает на 404.html, на которой стоит редирект на хомпейдж. перейдя на хомпейдж — у него в referer будет 404.html, а не «ресурс А»
единственный способ сохранить referer — серверный редирект.
Но вот есть множество проектов, которые сделаны на столько коряво, что и на /favicon отдается 404.html и даже на ошибочный рест запрос тоже 404.html словить можно.
Запись в базу — это тупость, без сомнения. Судя по всему, автор хотел нагнать паники «Мы все умрем».
А так же бизнес кейсы бывают разные. Не все делается на фронтенде, как бы этого не хотелось многим.
А еще есть прикол с Referer при редиректе через js (иногда это тоже важно). При серверном редиректе referer нового запроса будет первоначальная страница, а при js редиректе — текущая страница.
Но дополнительный запрос на главную с поднятием и выполнением кучи кода, иногда даже с хождением в базу будет.
В результате любой 404 может превратиться в нагрузку на сервер.
Проблема для продакшена не частая — почти любой сайт имеет favicon, но тем не менее.
А поисковики разве не повышают приоритет таких сайтов?
Если повышают, то это можно воспринимать как SEO оптимизация.
Но в указанном примере есть проблема: в настройках стоит 8 знаков на 1 таб, если было бы 4 — было бы красивее.
Обычно табы в 4 символа хорошо сочетаются с языками в которых короткие ключевые слова: def, var, let, val; потому их там и любят применять.
зы: я предпочитаю пробелы.
Смотря какой тул использовать. Если использовать качественный — то все будет нормально выравниваться, если в простом блокноте работать — да, будет не удобно.
зы: я уже и забыл, когда сам делал отступы в коде.
Интернеты должны быть свободны!
Вот тут то и будет извращение. Вместо того, чтобы просто писать на js, часть логики будет на java(gwt), а часть на js. И в этом случае все так же придется переключаться между java и js.