Да, блок кода в let не делает ничего полезного. Данный участок кода мы использовали для простого примера, чтобы показать безопасную работу с nullable типами.
Автор проверял, но опечатки случаются со всеми) Спасибо, что внимательно прочитали статью. Вот работающий код:
nullableString?.let { str ->
// Блок кода, который должен выполниться, если nullableString не равен null
val length: Int = str.length
} ?: run {
// Блок кода, который будет выполнен, если nullableString равен null
println("nullableString равен null")
}
По поводу data-классов без наследования: Kotlin активно использует композицию вместо наследования, что способствует более гибкой и расширяемой архитектуре. Data-классы не наследуются, чтобы избежать потенциальных проблем, связанных с этим.
По поводу сравнения с Java: вы правы. Kotlin является оберткой для Javа. Компания Jetbrains поставила перед собой цель — создание нового языка программирования, который был бы лучше, чем Java, но все еще функционально совместим с ним. На наш взгляд, у них это получилось.
Статья посвящена не только преимуществам и недостаткам языка, в ней рассказывается про базовые концепции Kotlin, из которых и вытекают плюсы и минусы. Они прослеживаются по мере разбора отдельных тем. Например, в блоках про null safety мы выделили плюс — избежание NullPointerException. В блоке про lateInit мы рассказали про минус этого инструмента, а также что привело к его добавлению.
В данном примере запущенные корутины работают параллельно друг другу и выполняются в разных потоках из пула потоков, предоставляемого Dispatchers.IO. Кроме того, когда корутина возобновляет свою работу (в данном примере после delay(1_000)), она может быть продолжена на любом из свободных потоков, представленных в пуле потоков в Dispatchers.IO. Порядок выполнения и вывода сообщений "tick 1" и "tick 2" не гарантирован и может меняться из-за асинхронной природы корутин и их запуска в разных потоках.
Давайте рассмотрим на примере диспатчера из вашего вопроса (то же самое будет касаться и других диспатчеров):
Допустим, при запуске корутины мы передаем Coroutine Context, а именно Dispatcher.Default, размер пула потоков которого равняется количеству ядер CPU.
Корутина запускается на свободном потоке из пула потоков Dispatcher.Default.
Когда корутина приостанавливается, она освобождает поток и он, скажем так, возвращается обратно в пул потоков Dispatcher.Default.
Когда корутина продолжит свою работу, для нее будет назначен свободный поток из диспатчера Default, но не факт, что это будет тот же поток, на котором она работала раньше.
Возможно, неточно сформулирована мысль в отношении Dispatchers.Unconfined.
Dispatchers.Unconfined — это особый диспетчер, который не привязан к конкретному потоку, т.е. поток может изменяться во время выполнения корутины. Корутина, запущенная с использованием Dispatchers.Unconfined, начинает свое выполнение на текущем потоке, но может продолжить выполнение на любом другом потоке, доступном в пуле потоков.
Вы правы, dispatcher main.immediate — это диспетчер, который может быть использован в контексте корутины. Он предназначен для немедленного выполнения задач в главном потоке. Данный диспетчер может быть полезен в ситуациях, когда необходимо выполнить корутину сразу же в основном потоке без задержки. Он часто используется в связке с lifecycle scope или viewmodel scope.
По поводу корутин-билдеров: в данной статье не рассматриваем, что происходит под капотом билдера, так как этот материал объемный и важно было донести суть того, что билдер обработает переданный ему блок кода(передаст в корутину) и запустит ее.
На счет cancel(): все верно, поэтому в статье приведен пример проверки — isActive внутри корутины, которая позволяет проверить, активен ли Job (не был ли отменен или завершен).
Многопоточность в Swift — обширная область для изучения. В этой статье мы рассматриваем основы многопоточности и рассказываем об основных инструментах. В каждый пункт можно углубляться подробнее, но это уже темы отдельных статей.
Вы правы, Data Race является одним из конкретных случаев Race Condition. Data Race представляет собой подтип Race Condition, в котором несколько потоков одновременно обращаются к общим данным, где хотя бы один из них выполняет операцию записи.
Race Condition более широкое понятие, которое охватывает различные ситуации, когда два или более потока конкурируют за доступ и изменение общих данных. В контексте Race Condition возможны различные проблемы, такие как неправильные результаты, несогласованность данных, сбои и непредсказуемое поведение программы.
Да, блок кода в let не делает ничего полезного. Данный участок кода мы использовали для простого примера, чтобы показать безопасную работу с nullable типами.
Автор проверял, но опечатки случаются со всеми) Спасибо, что внимательно прочитали статью. Вот работающий код:
По поводу data-классов без наследования: Kotlin активно использует композицию вместо наследования, что способствует более гибкой и расширяемой архитектуре. Data-классы не наследуются, чтобы избежать потенциальных проблем, связанных с этим.
По поводу сравнения с Java: вы правы. Kotlin является оберткой для Javа. Компания Jetbrains поставила перед собой цель — создание нового языка программирования, который был бы лучше, чем Java, но все еще функционально совместим с ним. На наш взгляд, у них это получилось.
Вы правы, Nothing — это класс. Но в данном контексте мы использовали обобщенное понятие, так как рассказывали про базовые типы Kotlin.
Статья посвящена не только преимуществам и недостаткам языка, в ней рассказывается про базовые концепции Kotlin, из которых и вытекают плюсы и минусы.
Они прослеживаются по мере разбора отдельных тем. Например, в блоках про null safety мы выделили плюс — избежание NullPointerException. В блоке про lateInit мы рассказали про минус этого инструмента, а также что привело к его добавлению.
В данном примере запущенные корутины работают параллельно друг другу и выполняются в разных потоках из пула потоков, предоставляемого Dispatchers.IO. Кроме того, когда корутина возобновляет свою работу (в данном примере после delay(1_000)), она может быть продолжена на любом из свободных потоков, представленных в пуле потоков в Dispatchers.IO. Порядок выполнения и вывода сообщений "tick 1" и "tick 2" не гарантирован и может меняться из-за асинхронной природы корутин и их запуска в разных потоках.
Давайте рассмотрим на примере диспатчера из вашего вопроса (то же самое будет касаться и других диспатчеров):
Допустим, при запуске корутины мы передаем Coroutine Context, а именно Dispatcher.Default, размер пула потоков которого равняется количеству ядер CPU.
Корутина запускается на свободном потоке из пула потоков Dispatcher.Default.
Когда корутина приостанавливается, она освобождает поток и он, скажем так, возвращается обратно в пул потоков Dispatcher.Default.
Когда корутина продолжит свою работу, для нее будет назначен свободный поток из диспатчера Default, но не факт, что это будет тот же поток, на котором она работала раньше.
Возможно, неточно сформулирована мысль в отношении Dispatchers.Unconfined.
Dispatchers.Unconfined — это особый диспетчер, который не привязан к конкретному потоку, т.е. поток может изменяться во время выполнения корутины. Корутина, запущенная с использованием Dispatchers.Unconfined, начинает свое выполнение на текущем потоке, но может продолжить выполнение на любом другом потоке, доступном в пуле потоков.
Вы правы, dispatcher main.immediate — это диспетчер, который может быть использован в контексте корутины. Он предназначен для немедленного выполнения задач в главном потоке. Данный диспетчер может быть полезен в ситуациях, когда необходимо выполнить корутину сразу же в основном потоке без задержки. Он часто используется в связке с lifecycle scope или viewmodel scope.
По поводу корутин-билдеров: в данной статье не рассматриваем, что происходит под капотом билдера, так как этот материал объемный и важно было донести суть того, что билдер обработает переданный ему блок кода(передаст в корутину) и запустит ее.
На счет cancel(): все верно, поэтому в статье приведен пример проверки — isActive внутри корутины, которая позволяет проверить, активен ли Job (не был ли отменен или завершен).
Многопоточность в Swift — обширная область для изучения. В этой статье мы рассматриваем основы многопоточности и рассказываем об основных инструментах. В каждый пункт можно углубляться подробнее, но это уже темы отдельных статей.
Вы правы, Data Race является одним из конкретных случаев Race Condition. Data Race представляет собой подтип Race Condition, в котором несколько потоков одновременно обращаются к общим данным, где хотя бы один из них выполняет операцию записи.
Race Condition более широкое понятие, которое охватывает различные ситуации, когда два или более потока конкурируют за доступ и изменение общих данных. В контексте Race Condition возможны различные проблемы, такие как неправильные результаты, несогласованность данных, сбои и непредсказуемое поведение программы.