Послушайте, либо вы тролль, либо не так меня поняли.
я привел пример людей, которые как и я считают final final final final визуальным мусором. на стековерфлоу и багтрекере эклипса. первые несколько ссылок в гугле
А про роботов а не людей — вот вам пример. Я вот например считаю, что изменять входные параметры функций — жуткий моветон. Но я никогда не заставлю никого объявлять их все файналами, а просто настрою линтер, который не даст закоммитить такой код без соответствующей аннотации «Я ВСЕ ПОНИМАЮ НО НЕ МОГУ ПО ДРУГОМУ»
и код чистый, и проблема решена. Вот и эти бесконечные final в жава идут еще из нулевых, когда программисты гуев, в основном, объявляли все файнал потому что в любой момент может понадобиться закинуть анонимный адаптер который без final работать не будет. Сейчас в этом никакого смысла нет. Тем более, что иммутабельные у нас далеко не все классы, и final может дать иллюзию безопасности, но по факту не защитит от банального изменения состояния класса.
Еще раз — очень многие ошибки о которы вы пишете можно решить правильной настройкой линтеров, не захламляя код final final final final. И вдобавок еще сотню тех, где любой final бессилен.
Еще раз — я далеко не идиот, и свой SCJP сдал еще 15 лет назад. Не спешите писать злобный ответ, а присядьте и подумайте, авось найдете в моих словах что полезное
Перечитайте еще раз обсуждение на стековерфлоу: I wish it was the default. But it isn't and I find the code more difficult to understand with finals all over.
Вот шикарный баг в эклипсе на эту тему:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=130888#c2
там говорится про оптимизацию кода, в 2008 это было актуально, сейчас давно уже нет. Почитайте также комментарии к этому ответу, где говорится, что сам пропагандист этого подхода не использует его в своем коде.
ок, вот более свежий пример
http://stackoverflow.com/questions/154314/when-should-one-use-final-for-method-parameters-and-local-variables
Еще раз проясню свою точку зрения — заставлять людей объявлять все локальные переменные FINAL бессмысленно и затрудняет чтение кода. Если ОЧЕНЬ хочется — можно настроить IDE или коммит-хуки в гите или свн, которые расставят все сами а не заставлять людей делать monkey-job. var/val в этом смысле немногим лучше, но, учитывая историю java, я очень сильно сомневаюсь в том, что введут даже одно новое ключевое слово, не говоря уже о двух сразу.
Послушайте, мы говорим о внутренних переменных метода, ваш пример немного высосан из пальца. При хорошей архитектуре код метода не превышает экрана, и легко видно, что где меняется.
Если говорить про удобство чтения — то легко настроить иде так, чтобы она показывала переменные которые больше не изменяются после инициализации и не заставлять людей писать громоздкие конструкции. Если надо запретить изменять переменную — ну ок, поставь файнл, но такое бывает корайне редко и никто не помешает индусу этот файнл убрать.
Кстати, на стаковерфлоу большинство согласны со мной, так что ваша позиция как минимум не бесспорна
http://stackoverflow.com/questions/316352/why-would-one-mark-local-variables-and-method-parameters-as-final-in-java
А в вашем примере эта константа никак не должна быть внутренней переменной метода
Читаю их регулярно и могу сказать одно — если есть любой консервативный метод решить проблему — разработчики коре жава выберут его, даже если решение будет не самым оптимальным. Предлагаемое решение нарушает стройную логику языка — вроде как кейворд но не кейвод.
Вводить новую механику в язык ради такого кейса — может быть, но верится с трудом
Ок, круто, но зачем заставлять человека делать то, что легко сделает робот или ide?
Настройте хук на коммит который будет парсить ast и расставлять файнлы если уж очень хочется, а разработчик найдет куда можно намного более полезно потратить время
А зачем объявлять локальные переменные final? компилятор давным-давно научился сам это понимать для оптимизаций, и для использования в лямбдах final уже не нужен, компилятор все сам понимает
Только фиг нам скорее всего, а не var в Java — новое ключевое слово поломает такое количество кода, что разработчики Java никогда на это не пойдут. С момента запуска языка из новых ключевых слов ввели только strictfp и enum. Как бы не получили мы в итоге default вместо var и final default вместо val :)
Угу, я пока читал, было ощущение, что читаю про предметную область, в которой ничего не понимаю. Прочитал оригинал и все встало на свои места.
Для себя кстати отличное решение открыл — чистить html от вредного кода на клиенте через обработку DOM DocumentFragment. Через обычный DOM нельзя — могут выполниться скрипты на onerror, например, а через фрагмент — скрипты не выполняются.
А мы никогда на клиенте и не пытались это делать, на сервере намного удобнее. Опять же, низкая производительность XSLT — это миф, по крайней мере на Java
Самое забавное в том, что бесплатная ветка 9.1 поддерживает практически все enterprise-фишки, которые в 9.2 стали платными, ее мы и используем в продакшне уже 8 лет — полная поддержка XSLT 2.0, Java-биндинги и т. д. Если на вход подавать саксоновскую же tinytree — то она еще и супер-быстрая, 10-15 мс на трансформацию типичной странички.
а по поводу того, что есть более мощные шаблонизаторы — тут не соглашусь никак. Мощнее XSLT ничего еще не придумали, но эта мощь и стала главной проблемой — те, кто выучил XSLT в нулевых — выросли, а новое поколение перешло на более простые технологии
Подписи проверяют кеш-сервера?
А у вас нет защиты приватности на уровне обращений к файлам фото? Имея url приватного файла можно получить доступ к нему?
Успели испортить половину отличной вырезки, пока не отобрал и не сделал нормально на сковороде.
из той же тематики
я привел пример людей, которые как и я считают final final final final визуальным мусором. на стековерфлоу и багтрекере эклипса. первые несколько ссылок в гугле
А про роботов а не людей — вот вам пример. Я вот например считаю, что изменять входные параметры функций — жуткий моветон. Но я никогда не заставлю никого объявлять их все файналами, а просто настрою линтер, который не даст закоммитить такой код без соответствующей аннотации «Я ВСЕ ПОНИМАЮ НО НЕ МОГУ ПО ДРУГОМУ»
и код чистый, и проблема решена. Вот и эти бесконечные final в жава идут еще из нулевых, когда программисты гуев, в основном, объявляли все файнал потому что в любой момент может понадобиться закинуть анонимный адаптер который без final работать не будет. Сейчас в этом никакого смысла нет. Тем более, что иммутабельные у нас далеко не все классы, и final может дать иллюзию безопасности, но по факту не защитит от банального изменения состояния класса.
Еще раз — очень многие ошибки о которы вы пишете можно решить правильной настройкой линтеров, не захламляя код final final final final. И вдобавок еще сотню тех, где любой final бессилен.
Еще раз — я далеко не идиот, и свой SCJP сдал еще 15 лет назад. Не спешите писать злобный ответ, а присядьте и подумайте, авось найдете в моих словах что полезное
Вот шикарный баг в эклипсе на эту тему:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=130888#c2
там говорится про оптимизацию кода, в 2008 это было актуально, сейчас давно уже нет. Почитайте также комментарии к этому ответу, где говорится, что сам пропагандист этого подхода не использует его в своем коде.
ок, вот более свежий пример
http://stackoverflow.com/questions/154314/when-should-one-use-final-for-method-parameters-and-local-variables
Еще раз проясню свою точку зрения — заставлять людей объявлять все локальные переменные FINAL бессмысленно и затрудняет чтение кода. Если ОЧЕНЬ хочется — можно настроить IDE или коммит-хуки в гите или свн, которые расставят все сами а не заставлять людей делать monkey-job. var/val в этом смысле немногим лучше, но, учитывая историю java, я очень сильно сомневаюсь в том, что введут даже одно новое ключевое слово, не говоря уже о двух сразу.
Если говорить про удобство чтения — то легко настроить иде так, чтобы она показывала переменные которые больше не изменяются после инициализации и не заставлять людей писать громоздкие конструкции. Если надо запретить изменять переменную — ну ок, поставь файнл, но такое бывает корайне редко и никто не помешает индусу этот файнл убрать.
Кстати, на стаковерфлоу большинство согласны со мной, так что ваша позиция как минимум не бесспорна
http://stackoverflow.com/questions/316352/why-would-one-mark-local-variables-and-method-parameters-as-final-in-java
А в вашем примере эта константа никак не должна быть внутренней переменной метода
Вводить новую механику в язык ради такого кейса — может быть, но верится с трудом
Настройте хук на коммит который будет парсить ast и расставлять файнлы если уж очень хочется, а разработчик найдет куда можно намного более полезно потратить время
Только фиг нам скорее всего, а не var в Java — новое ключевое слово поломает такое количество кода, что разработчики Java никогда на это не пойдут. С момента запуска языка из новых ключевых слов ввели только strictfp и enum. Как бы не получили мы в итоге default вместо var и final default вместо val :)
рут их сертификата по лицензии требует ограничить доменные имена не .mil доменами, а такая запись в сертификате портит его не а ХР
разбираются пока, но перспективы туманны. а счастье было так близко
Для себя кстати отличное решение открыл — чистить html от вредного кода на клиенте через обработку DOM DocumentFragment. Через обычный DOM нельзя — могут выполниться скрипты на onerror, например, а через фрагмент — скрипты не выполняются.
Оказалось, что такое решение уже есть: github.com/cure53/DOMPurify
а по поводу того, что есть более мощные шаблонизаторы — тут не соглашусь никак. Мощнее XSLT ничего еще не придумали, но эта мощь и стала главной проблемой — те, кто выучил XSLT в нулевых — выросли, а новое поколение перешло на более простые технологии
sourceforge.net/projects/saxon/files/Saxon-B/9.1.0.8