Климат ужасный: летом жара +35 и влажность 90%, зимой то дубак -15..-20, то в любом диапазоне от -5 до +15. Весны вообще нет, зато осень прям хороша.
Чтобы передвигаться на велосипеде надо иметь стальные яйца, водителей не просто так начали называть massholes.
> 7 mb для hello world release, на мой взгляд, многовато.
Как часто вы пишите приложения уровня hello world?
Если обычное приложение в итоге все равно занимает под 100 мегабайт, какая разница, что оно чуть больше?
Я говорил про null на входе :) Optional только на выходе выдается.
Ситуация примерно такая: Optional<Integer> isInteger(String s)
В случае ошибки парсинга возвращаем Optional.empty(), что будет если s = null? И что делать если в моем случае null — вполне себе допустимое значение, и я хочу получить назад null? Если кидать NullPointerException, то это как бы ломает всю идею использования Optional.
В джаве так-то тоже есть Exception, который не должен являться фатальным, и Error, который даже не имеет смысла ловить.
null — не всегда показатель ошибки, зачастую это вполне себе first-class value. К примеру, что должен этот метод вернуть, если ему передали null string?
Я бы в этом случае больше предложил использовать что-то с тройным состоянием, вроде Mono из Project Reactor: оно может содержать значение, если все ок, может не содержать никакого значения, если был null, или же содержать исключение, если случилась ошибка.
Не вижу «правильности» :)
В обоих случаях мы выполняем примерно одну и ту же работу: надо пробежаться по строке и определить, является ли каждый символ составным элементом числа.
Отдельный метод в джаве будет выглядеть ооооооооочень странным, поскольку сделает столько же работы, сколько и полноценный парсинг, но пользы принесет меньше. Я, отчасти, понимаю, зачем это нужно в php, ввиду очень своеобразной системы типов, но в языках с более строгой системой типов это будет просто мусором в пространстве имен.
А уж использование регулярных выражений для проверки на число — это прям совсем смешно :)
Стриминг там не запрещен, раздача запрещена. Плюс, это письмо вполне может быть скамом, мол, вы нам напрямую штраф оплатите, а то в суд пойдем и там уж вас ого-го!
Pair/Tuple не дают никакой информации о том, что же там за данные. Вот функция doOperation() возвращает Pair<String, Integer> — что это за данные? Без документации не разобраться.
Если вернуть класс с полями типа String errorMessage, Integer errorCode — сразу понятно, что же это за зверь.
Чтобы передвигаться на велосипеде надо иметь стальные яйца, водителей не просто так начали называть massholes.
Я много лет использовал keepassx + dropbox, но в конце-концов удобство победило.
Программисты и так едут постоянно.
Как часто вы пишите приложения уровня hello world?
Если обычное приложение в итоге все равно занимает под 100 мегабайт, какая разница, что оно чуть больше?
Может и называется, вопрос в контракте метода.
Почему нельзя? Можно.
Я говорил про null на входе :) Optional только на выходе выдается.
Ситуация примерно такая:
Optional<Integer> isInteger(String s)В случае ошибки парсинга возвращаем
Optional.empty(), что будет еслиs = null? И что делать если в моем случае null — вполне себе допустимое значение, и я хочу получить назад null? Если кидатьNullPointerException, то это как бы ломает всю идею использованияOptional.В джаве так-то тоже есть
Exception, который не должен являться фатальным, иError, который даже не имеет смысла ловить.Я бы в этом случае больше предложил использовать что-то с тройным состоянием, вроде Mono из Project Reactor: оно может содержать значение, если все ок, может не содержать никакого значения, если был null, или же содержать исключение, если случилась ошибка.
В обоих случаях мы выполняем примерно одну и ту же работу: надо пробежаться по строке и определить, является ли каждый символ составным элементом числа.
Отдельный метод в джаве будет выглядеть ооооооооочень странным, поскольку сделает столько же работы, сколько и полноценный парсинг, но пользы принесет меньше. Я, отчасти, понимаю, зачем это нужно в php, ввиду очень своеобразной системы типов, но в языках с более строгой системой типов это будет просто мусором в пространстве имен.
А уж использование регулярных выражений для проверки на число — это прям совсем смешно :)
Если вернуть класс с полями типа String errorMessage, Integer errorCode — сразу понятно, что же это за зверь.
Грустно, конечно, я туда в декабре закинул баксов триста, как раз, чтобы хватило на год-полтора.