Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!22.09.2024
Ще про ізоляцію даних у Swift
Ох і Swift! Такої суворої системи ізоляції я ще не бачив (ну, хіба в Rust, але там я далеко не заходив.) Не очікував такого від мови, яка для екосистеми Apple значить те ж саме, що JavaScript для браузерів — тобто це перша та головна мова, з якою стикаються всі.
Так, я звик до async/await в JavaScript. Як і до “розфарбовування функцій” - тобто обовʼязкового маркування функцій, де є await. Але якщо в JS async/await зʼявляється практично тільки там, де є ввід/вивід — то у Swift будь-яка заявка на рівночасність потребує async/await та розфарбовування.
Причому рівночасність у Swift нам потрібна, щоб робити програми, де не гальмує інтерфейс. Втім, я б радив почати з @MainActor всюди, а потім впроваджувати акторів обережно та обмежено, бо вони досипають в код несподіваних ускладнень. Наприклад:
-
Так виходить, що й конструктори, й звернення до атрибутів, й передача замикань — все це “розфарбовується” за актором-власником, і все потребує особливого ставлення — тобто якісь виклики стають
async, а якісь ні. Переорганізація коду змушує це переглядати, разом з місцями виклику. -
Якщо в класі є атрибут, що належить до іншого актору, та ми його ініціалізуємо, то сам конструктор стає асинхронним (оскільки містить асинхронний конструктор атрибута.)
-
Також не всі типи можна передавати з актора акторові; це змусить вас переписати потоки даних. Зокрема моделі SwiftData потребують ізоляції, тож замість моделей доведеться передавати ідентифікатори. Ще не можна передавати нічого змінного. Хочеш повернути результати — роби це у функціональному стилі, без мутації.
-
Взагалі понад усе дратує саме те, що рефакторинг коду акторів змінює цілі шари функцій з синхронних в асинхронні та навпаки. Чого практично не трапляється в JavaScript, бо там
async/awaitвипливає з потреб коду (наприклад, в читанні файлів), а у Swift - суто з його організації. Отак.