Согласен, что создание объекта для пользовательской информации визуально упростит код. Однако, что-то мне подсказывает, что таким образом мы создадим еще одну сущность, которая будет зависеть от HttpServletRequest, получая все его данные. То есть мы встроим еще один слой абстракции, через который метод login буден по-прежнему зависеть от HttpServletRequest, но уже опосредованно.
Кстати, коллеги, поделитесь пожалуйста опытом. Ситуация. Ты написал статью на Хабре (может и еще где-то). В ходе обсуждения выяснилось, что нужно что-то поправить. Есть тут какие-то best practice?
Просто бесследно перетереть переосмысленный кусок текста или как-то это оформить с указанием на то, что ранее было неверно, а верно так-то.
Ваша правда. Python упоминается в документации дважды. Однако, оба раза по отношению к быстрой сортировке (исходный код Arrays, строки 454-455, исходный код TimSort, строки 37-40). Поправлю.
Тут хочется вспомнить анекдот. Физику, математику и инженеру дали задание измерить объем красного резинового шара. Физик погрузил шар в воду и измерил объем вытесненной жидкости. Математик измерил длину окружности, вычислил радиус и взял тройной интеграл. Инженер достал из стола «Таблицу объемов красных резиновых мячей» и нашел нужное значение.
Иногда достаточно знать где посмотреть, иногда нужно уметь сделать руками.
Вы правы, спасибо за замечание! Я привожу среднюю сложность для «основных» алгоритмов и сложность в лучшем случае для дополнительных. Я исходил из того, что имеет смысл применять дополнительный алгоритм, если он показывает производительность лучше основного. А с алгоритмами insertion sort и binary insertion sort это происходит только в лучшем случае. Поэтому и указал такие параметры. Я собирался сделать сноску об этом, видимо что-то отвлекло. Спасибо, что заметили.
Просто бесследно перетереть переосмысленный кусок текста или как-то это оформить с указанием на то, что ранее было неверно, а верно так-то.
Иногда достаточно знать где посмотреть, иногда нужно уметь сделать руками.