В примере с таймером написано: «The timer starts when the presenter is created and stops only when the presenter is destroyed. You can minimize, rotate, open another screen, but the timer will still work. The presenter will be destroyed only when the activity is finished (for instance, by pressing the back button).»
Провожу такой тест:
1. Запускаю экран с таймером, дожидаюсь, пока дотикает до 10.
2. Выхожу на домашний экран.
3. Симулирую «убиение процесса» командой: «adb shell am kill example.reamp».
4. Возвращаюсь в приложение, таймер при этом сбрасывается на 0.
Так и задумано, или таймер после убийства не должен сбрасываться?
Из плюсов: много чего есть на борту, что бы потыкать, включая 16-битный RGB порт.
Из обнаруженных недостатков: на борту оказался «поддельный» (фейковый) USB-UART адаптер (PL2303), из-за чего последние официальные драйверы не ставятся.
Ну я тоже программирую на Go, решая те задачи, которые для него хорошо подходят с моей точки зрения: небольшие переносимые утилиты командной строки.
Кроме этого, упомянутая проблема «стремления пользы к нулю» справедлива не только для Go, а вообще для любой системы, в которой будет использоваться подобная конструкция (строка ошибка). В C++ это будет:
Конечно в Java вы тоже можете написать библиотеку, которая вместо FileNotFound будет возвращать некий код (как в C), но так не делают, ибо так не принято.
Да ладно!
Вот, например: «boolean File.delete()», «boolean File.mkdir()» и т.п.
Обычно добавляется полезная информация и ошибка заворачивается в что-то вроде return nil, fmt.Errorf(«decode: %s», err) или заворачивается в свой тип, реализующий интерфейс error — return nil, DecodeError{line: line, err: err}
Очевидно, что полезность «return nil, fmt.Errorf('decode: %s', err)» стремится к нулю, т.к. эта ошибка для пользователя (причем, без учета i18n), а не программы, ее нельзя категоризировать и далее каким-либо осмысленным образом обработать.
А возвращение в стиле «return nil, DecodeError{line: line, err: err}», по-моему, упрется в то же, что и упираются исключения — лень программиста завести «DecodeError» и написать правильно.
Подскажите, а в iOS так же приходится плясать с бубном, как и в Android вокруг onSaveInstanceState(), Fragment.setRetainInstance() и т.п., или там проще?
Вы можете сделать любой интерфейс. Когда хотите. До появления реализации. После появления. Не важно.
А вы не думали, что можно было вообще отказаться от интерфейсов и снять это ограничение? Зачем ввели интерфейсы?
В большом приложении, даже с несколькими программистами (а не десятками) беспорядок в коде и спецификациях (интерфейсах) приведет в тупик. Система обрушится под весом собственного беспорядка, будут постоянно всплывать ошибки при доработках в самых неожиданных местах, а в кабинетах и комнатах разработчиков будет стоять сплошной мат.
Поэтому и придумали SOLID, а «Когда хотите» не рекомендуют.
В примере с таймером написано: «The timer starts when the presenter is created and stops only when the presenter is destroyed. You can minimize, rotate, open another screen, but the timer will still work. The presenter will be destroyed only when the activity is finished (for instance, by pressing the back button).»
Провожу такой тест:
1. Запускаю экран с таймером, дожидаюсь, пока дотикает до 10.
2. Выхожу на домашний экран.
3. Симулирую «убиение процесса» командой: «adb shell am kill example.reamp».
4. Возвращаюсь в приложение, таймер при этом сбрасывается на 0.
Так и задумано, или таймер после убийства не должен сбрасываться?
Из плюсов: много чего есть на борту, что бы потыкать, включая 16-битный RGB порт.
Из обнаруженных недостатков: на борту оказался «поддельный» (фейковый) USB-UART адаптер (PL2303), из-за чего последние официальные драйверы не ставятся.
О пользе типизированных ошибок, которые часто ленятся использовать программисты с качестве возвращаемого результата и в качестве объекта исключения.
Ха-ха-ха. Встречал я подобный код, только вместо i18n был стразу MessageBox. Чего мелочится-то? :-)
В 99% случаях это нарушение роли компонента в системе.
https://stackoverflow.com/questions/6248404/c-exceptions-is-throwing-c-string-as-an-exception-bad
Ну я тоже программирую на Go, решая те задачи, которые для него хорошо подходят с моей точки зрения: небольшие переносимые утилиты командной строки.
Кроме этого, упомянутая проблема «стремления пользы к нулю» справедлива не только для Go, а вообще для любой системы, в которой будет использоваться подобная конструкция (строка ошибка). В C++ это будет:
throw «some error useless description»;.
Да ладно!
Вот, например: «boolean File.delete()», «boolean File.mkdir()» и т.п.
Очевидно, что полезность «return nil, fmt.Errorf('decode: %s', err)» стремится к нулю, т.к. эта ошибка для пользователя (причем, без учета i18n), а не программы, ее нельзя категоризировать и далее каким-либо осмысленным образом обработать.
А возвращение в стиле «return nil, DecodeError{line: line, err: err}», по-моему, упрется в то же, что и упираются исключения — лень программиста завести «DecodeError» и написать правильно.
и сказать, что Go произошел от Delphi.
Там речь не о различиях вообще, а о том, что Go проще, чем C.
Думаю там видно, что:
отличается от:
и «сишник» этот код на Go не поймет и будет спотыкаться при его написании (хотя бы из-за смены порядка указания имя/тип).
Ответ: «и C, и Go являются тьюринг-полными языками программирования», конечно, правильный, но я хотел бы услышать что-то более конкретное.
То, что я вижу в Go vs C:
Что общего с C/C++ вы нашли в Go?
Я, конечно, извиняюсь, но по-моему, Go радикально отличается от C и C++. Даже не знаю, что там может быть общего.
А можно где-то это грузинский блокчейн увидеть, пощупать? Где можно скачать данные этого блокчейна?
Какой-то странный диапазон для оптимума вы выбрали. В Европах в городе ограничение 50 км/ч.
Спецификация пишется до реализации, а не после. И не спецификация зависит от реализации, а реализация от спецификации.
Это простая вещь, но почему-то многие ее не могут осознать.
См. так же: Контрактное программирование.
А вы не думали, что можно было вообще отказаться от интерфейсов и снять это ограничение? Зачем ввели интерфейсы?
В большом приложении, даже с несколькими программистами (а не десятками) беспорядок в коде и спецификациях (интерфейсах) приведет в тупик. Система обрушится под весом собственного беспорядка, будут постоянно всплывать ошибки при доработках в самых неожиданных местах, а в кабинетах и комнатах разработчиков будет стоять сплошной мат.
Поэтому и придумали SOLID, а «Когда хотите» не рекомендуют.