Живут они с надеждой на лучшее, наверное.
В принципе, можно вынести такие операции в отдельный ограниченный пул горутин, в этом случае, когда все станет плохо, система в целом может и не развалиться.
http://caniuse.com/#search=MSE — API Media Source Extensions как раз придуманы для потокового видео в браузере, в частности, MPEG DASH. DASH, конечно, не совсем потоковый, а chunked, но это даже плюс.
YouTube HTML5 вроде бы использует MSE по возможности.
Однако, тут надо отметить, что у Flash/RTMP latency меньше.
Для этого предусмотрены стратегии, применяются либо на весь view-интерфейс, либо на отдельные методы, можно писать свои. Подробнее в посте и исходниках.
>> некорректно сделать инъекцию
>> забыть вызвать setup метод
И что, это штатная ситуация, которая должна быть обработана на уровне отдельного объекта? Конечно нет, это ваша ошибка, которую вам нужно как можно скорее исправить. Значит, использование nullable, которое вы предлагаете в посте совершенно некорректно. Зачем лепить проверки на null на поле, которое в нормальном состоянии всегда проинициализировано?
Для таких случаев нужно использовать Delegates.notNull или lateinit — в зависимости от прочих условий. Они следят за выполнением контракта «доступ к полю до инициализации — исключительная ситуация». Дальше вы это исключение обрабатываете или нет, это отдельный вопрос.
Почему же тогда я назвал lateinit «практически костылем»? Потому что он дублирует на уровне языка функциональность, которая реализована в стандартной библиотеке как delegated property Delegates.notNull.
Зачем он введен? Затем, что у delegated property в общем случае нет backing field, на который может потребоваться применить аннотацию, скажем, инжектора.
То есть, lateinit это элемент совместимости совместимости с деталями платформы, которые отсутствуют в языке в явном виде. То есть, практически костыль.
Исключительно для того, что сказано в документации, IMHO, в первую очередь для injected-объектов. С другими кейсами я лично не сталкивался, может быть, тесты — но их я еще не писал.
IMHO, lateinit это практически костыль для ограниченного набора случаев, и не стоит его использовать, когда можно обойтись чем-то другим.
>> lateinit
>> lateinit var без аннотации
Вы просто не поняли, зачем нужен lateinit.
Для того, что у вас написано, действительно нужны Delegates.nonNull или nullable var.
>> Почему не стоит думать о Nullable как об Option
А почему вы решили, что стоит?..
>> внутри run… что надо использовать?
Из сигнатуры же очевидно, что this.
Я все же сомневаюсь, что этого достаточно, чтобы сказать «С++ сложнее С#».
По своему опыту я могу сказать, что на С# можно сесть что-то писать по делу, не имев с ним дела до этого. С С++ у меня так не получилось.
Не уверен, однако, что этого достаточно, чтобы утверждать обратное.
А вот предположим, мы хотим создать в своем коде отдельную сущность Router, тот самый, из соседней статьи про VIPER, и вызывать его методы из презентеров. Естественно, хочется обойтись без бойлерплейта, но не очень понятно как, роутеру для запуска активити нужен контекст — текущая активити.
Простое и некрасивое решение — явно вызывать Presenter.start(this) в OnCreate/OnStart. А есть ли решение красивее?
Я не знаю точно, что он имел ввиду, но сейчас annotation processors работают — я играюсь с проектом на Kotlin и Moxy, где все строится на аннотациях, полет нормальный.
А вас не посещала идея сделать транспилер в Go вместо нативного таргета?
У него очень приятный рантайм, но так себе язык — как и у всех ваших таргет-платформ.
Из этих двух критериев можно сделать вывод — не заморачиваться с кроссплатформенностью и идти путем наименьшего сопротивления.
Если дело будет идти к кроссплатформенности, конечно, переписать на Qt — главное выбрать правильный момент.
Вообще, не обязательно.
Я бы сказал, чеклист примерно следующий:
— тривиальные императивные конструкции
— ООП
— параметрический полиморфизм(вот тут лично я впаялся в ко-/контравариантность)
— ФВП.
С таким бэкграундом можно учить синтаксис, пройти kotlin koans и садиться писать.
Впрочем, Java стоит знать хотя бы на уровне свободного чтения — библиотеки-то все на ней.
Живут они с надеждой на лучшее, наверное.
В принципе, можно вынести такие операции в отдельный ограниченный пул горутин, в этом случае, когда все станет плохо, система в целом может и не развалиться.
YouTube HTML5 вроде бы использует MSE по возможности.
Однако, тут надо отметить, что у Flash/RTMP latency меньше.
На сетевое IO. Файловое, консольное, subprocess — блокируют тред планировщика.
>> забыть вызвать setup метод
И что, это штатная ситуация, которая должна быть обработана на уровне отдельного объекта? Конечно нет, это ваша ошибка, которую вам нужно как можно скорее исправить. Значит, использование nullable, которое вы предлагаете в посте совершенно некорректно. Зачем лепить проверки на null на поле, которое в нормальном состоянии всегда проинициализировано?
Для таких случаев нужно использовать Delegates.notNull или lateinit — в зависимости от прочих условий. Они следят за выполнением контракта «доступ к полю до инициализации — исключительная ситуация». Дальше вы это исключение обрабатываете или нет, это отдельный вопрос.
Почему же тогда я назвал lateinit «практически костылем»? Потому что он дублирует на уровне языка функциональность, которая реализована в стандартной библиотеке как delegated property Delegates.notNull.
Зачем он введен? Затем, что у delegated property в общем случае нет backing field, на который может потребоваться применить аннотацию, скажем, инжектора.
То есть, lateinit это элемент совместимости совместимости с деталями платформы, которые отсутствуют в языке в явном виде. То есть, практически костыль.
IMHO, lateinit это практически костыль для ограниченного набора случаев, и не стоит его использовать, когда можно обойтись чем-то другим.
>> lateinit var без аннотации
Вы просто не поняли, зачем нужен lateinit.
Для того, что у вас написано, действительно нужны Delegates.nonNull или nullable var.
>> Почему не стоит думать о Nullable как об Option
А почему вы решили, что стоит?..
>> внутри run… что надо использовать?
Из сигнатуры же очевидно, что this.
По своему опыту я могу сказать, что на С# можно сесть что-то писать по делу, не имев с ним дела до этого. С С++ у меня так не получилось.
Не уверен, однако, что этого достаточно, чтобы утверждать обратное.
Простое и некрасивое решение — явно вызывать Presenter.start(this) в OnCreate/OnStart. А есть ли решение красивее?
У него очень приятный рантайм, но так себе язык — как и у всех ваших таргет-платформ.
TL;DR: свои, kotlin.jvm.functions.Function[0..22];
В принципе, что свои, можно было заключить из того, что они работают на Android, но я решил перепроверить.
> ПРОСТОЕ
Из этих двух критериев можно сделать вывод — не заморачиваться с кроссплатформенностью и идти путем наименьшего сопротивления.
Если дело будет идти к кроссплатформенности, конечно, переписать на Qt — главное выбрать правильный момент.
Я бы сказал, чеклист примерно следующий:
— тривиальные императивные конструкции
— ООП
— параметрический полиморфизм(вот тут лично я впаялся в ко-/контравариантность)
— ФВП.
С таким бэкграундом можно учить синтаксис, пройти kotlin koans и садиться писать.
Впрочем, Java стоит знать хотя бы на уровне свободного чтения — библиотеки-то все на ней.