Как стать автором
Обновить
39
0
Борис Ванин @fogone

Пользователь

Отправить сообщение
Простите, я вот тоже не понял, какое же вы предлагаете использовать название вместо «коды ошибки», которое наверное не совсем верное в том смысле, что кодами обычно называют какие-то числа или возможно перечисления, а не целые структуры, но подход-то возвращения ошибки из метода тот же самый? Напишите, пожалуйста, как в го-мире принято называть такой способ обработки ошибок ответом на этот комментарий, чтобы все кто тоже не понял, смог бы посмотреть сюда и удовлетворить своё недопонимание.
Это же была ирония про хейтеров, наверное слишком завуалированная получилась. В том смысле, что в статьях написанных фанбоями появляются люди, которые задают вопросы на которые не даёт ответ методичка и портят кайф от незамутненного фанатического экстаза.
Ну а вы придумали про элитарных разработчиков и обобщили свой опыт, решив что если вам не удалось воспользоваться эксепшенами, то вряд-ли и кому-то другому удастся. Так что мне показалось, что наше общение идёт в очень теплой, располагающей к взаимности атмосфере.
Не трудитесь искать, я верю, что такой документ есть. Я даже верю, что есть такое исследование. Более того, я даже могу предложить, что действительно такой большой процент кода использует эксепшены как-то однобоко. Только что это доказывает? Лишь то, что видимо эксепшены удобно так использовать. Откуда уверенность, что это плохо конкретно в этом коде?
Вот подумайте сами, если бы го был мне неинтересен, зачем бы я стал заходить в эту статью? А я её прочёл да ещё и вместе с комментариями, видимо какой-то интерес есть? Проблемы только две. Мне кажутся некоторые решения этого языка немного странным и я пытаюсь понять, чем они обусловлены, но когда вижу такую аргументацию, то мне кажется, что я все же чего-то не понимаю. И второе, что вечно преследует го — это хейтеры. У языка похоже что-то не чисто с кармой, ему просто катастрофически не везёт с хейтерами, они наводняют любой пост и не дают любителям писать на го наслаждаться их любимым языком.
Я утрировал, чтобы выделить общую мысль, а вы уже «идиотов» приняли на свой счёт. Да и не моя аргументация строится на тезисе «пусть неудобно, зато никто не ошибётся», я лишь эмоционально её раскрасил.
Точно 78%? По вашей ссылке на исследование не смог найти точный процент…
Боюсь представить эту вашу практику, которая показывает на какое-то одно место о котором все говорят, но никто не может объяснить конкретнее.
Ваша позиция по отношению к го мне примерно ясна из предыдущего диспута, можно было не писать ещё один такой длинный комментарий.
Вы сменили тему, я писал про аргументацию и её свойство отталкивать от использования языка. Что же до эксепшенов, раз уж вы перевели на них тему, то я не говорил, что в го нужны эксепшены, так же как и обратного.
простите, я тут немного влезу. Просто когда я читаю такую аргументацию, я это слышу примерно так: да, мы сделали неудобно для использования, зато любой идиот это поймёт. Значит вторых использующих язык предполагается даже больше чем тех кому важно удобство и кто в состоянии воспользоваться эксепшенами так, чтобы ничего себе не отстрелить. Тут вот как раз я и понимаю, что это не мой язык, я ничего против него не имею, пользуйтесь на здоровье если нравится и решает задачи, но я воздержусь, спасибо.
Хорошая статья, теперь осталось только написать вторую часть: Как воспитать конструктивную культуру в компании.
так и в ногу можно попасть. Даже не особо целясь
заведите себе статический util класс с этими методами

В теории, конечно, статический метод можно превратить в компаратор ссылкой на этот метод, но компаратор — это ведь далеко не единственное, что не имеет состояния. Например стратегии часто не имеют состояния, их вы тоже будете статическими методами делать?

А вот что касается синглтона с состоянием, то я совсем перестал их использовать. Только иногда ThredLocal и то, по возможности стараюсь избегать.
Лучше поставить вопрос по-другому: какой смысл получать разные объекты, если у них всё равно нет состояния и соответственно проблем совместного использования? Например Comparator без параметров, есть ли смысл его каждый раз инстанцировать?
я же не сказал, что нельзя, я сказал, что он object хорош для другого. Т.е. для обычного синглтона его конечно тоже можно использовать, просто не надо.
Вот есть очень неахота иметь бойлерплейт код конструктора, где значения просто в поля записываются, то можно ломбок попробовать, в целом с нынешней поддержкой плагинов для иде с ним достаточно комфортно работать. Это конечно может быть не очень уважительно, если это опенсорс, но для внутренних или своих проектов, вполне ок.
В самых простых случаях даже не обязательно использовать di-контейнер, можно «инжектить» в конструктор самому. Насоздавал все нужные инстансы в одном методе и раздал их в конструкторы, вот и вся недолга.
object как в котлине хорош для реализаций, для которым достаточно одного инстанса и которые не имеют состояния (например компаратор какой-нибудь). Это хоть и синглтон в каком-то смысле, но он не имеет состояния и обычно может быть достаточно смело использован, хотя я временами и такие вещи выношу в конструктор, если считаю, что такая параметризация может иметь смысл. Еще object-ы можно использовать как контейнер для фабричных функций и тому подобные вещи без состояния. Делать же object-ы с состоянием это тоже самое, чтобы обычные синглтоны, только что более красиво, потому что язык скрывает ленивую инициализацию от глаз разработчика.
Вы искреннее считаете, что депенденси инжекшн нужен для того, чтобы конструкторы не писать?
Инжекшн в поля — это же фу.
на котлине:
клиент
val html = URL("http://google.com").openStream().reader().readText()

сервер
fun main(args: Array<String>) {
    embeddedServer(Netty, 8080) {
        routing {
            get("/") {
                call.respondText("Hello, world!", ContentType.Text.Html)
            }
        }
    }.start(wait = true)
}
кто-то интегрирует системы, а кто-то библиотеки в системе, всем нужны свои инструменты

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Зарегистрирован
Активность