Video není dostupné.
Omlouváme se.
Method Dispatch в Swift (и не только) - Mad Brains Техно 5.07.19
Vložit
- čas přidán 14. 08. 2024
- Техно - это внутренний еженедельный митап Mad Brains, на котором мы делимся опытом, знакомимся с актуальными технологиями и темами в мобильной разработке и не только.
Так как мы занимаемся и кроссплатформенной разработкой, и нативной (под обе платформы), на нашем канале выходят видео по разным технологиям. Найти то, что интересно именно тебе. легче всего на странице плейлистов.
Ссылки и материалы из наших новых видео, полезные статьи в телеграм-канале
t.me/skills_by_mad
Вакансии
bit.ly/MadBrainsWork - HeadHunter
Мы в соцсетях:
bit.ly/MadBrainsSite - Сайт
bit.ly/MadBrainsFB - Facebook
bit.ly/MadBrainsVK -Вконтакте
bit.ly/MadBrainsBe - Behance
bit.ly/MadBrainsInst - instagram
Отличный доклад и интересные дискуссии!
как обычно у мб лучшие доклады на важные темы
final проставляется автоматически в момент компиляции только, если включен флаг whole module optimization, надо было уточнить)
Да, все верно) Не помню уже, почему не упомянул это
если я правильно понял и для методов класса и для самих классов, от которых никто не наследовался?
Спасибо
Шикарно, лайк
Решение о том, какая диспетчеризация использовать для экстеншенов протокола, связано с производительностью и безопасностью типов в Swift. Давайте разберемся подробнее.
1. **Производительность:**
- Статическая диспетчеризация обычно более эффективна с точки зрения производительности, чем динамическая диспетчеризация. При статической диспетчеризации компилятор может принять решение о том, какой метод вызывать на этапе компиляции, что позволяет избежать накладных расходов, связанных с поиском методов во время выполнения программы.
2. **Безопасность типов:**
- Swift является языком с сильной типизацией, что означает, что компилятор проверяет типы во время компиляции, чтобы предотвратить ошибки во время выполнения. Использование статической диспетчеризации для экстеншенов протоколов помогает поддерживать эту сильную типизацию, поскольку компилятор может гарантировать, что методы, определенные в экстеншене протокола, будут доступны для всех типов, реализующих этот протокол.
3. **Поддержка расширений в будущем:**
- Статическая диспетчеризация также облегчает добавление новых методов в протоколы в будущих версиях Swift без необходимости изменения реализации всех типов, реализующих этот протокол. Это связано с тем, что методы, добавленные в протоколы, автоматически становятся доступными для всех типов, реализующих эти протоколы.
Хотя динамическая диспетчеризация имеет свои преимущества, такие как возможность переопределения методов в подклассах и динамическая загрузка классов во время выполнения, для экстеншенов протоколов статическая диспетчеризация обычно более предпочтительна в контексте Swift из-за упомянутых выше причин.
Отличное видео! А можно ли где-нибудь скачать саму презентацию?
Да, без проблем, в обмен на лайк и репост ;)
@George Ymydykov docs.google.com/presentation/d/1uqG-iIpoPPpKr1GeK-R7e9dXnhSYgtiZsk7AqwtYsCQ/edit?usp=sharing
docs.google.com/presentation/d/1uqG-iIpoPPpKr1GeK-R7e9dXnhSYgtiZsk7AqwtYsCQ/edit?usp=sharing
@@MadBrains ребят, помогите плиз разобраться, не могу найти объяснение, почему final func someMethod() {} будет диспатчится статически? ведь мы можем спокойно вызвать override final func viewWillLayoutSubviews() { super.... } и при этом Свифт пойдет в суперы искать первую реализацию.
То есть если в final классе нет сабклассов или функция override final func, то класс все еще может иметь родителей, а функция может брать поведения super. Разве Свифт не динамически побежит по таблице к суперам?
если я все правильно понимаю, то в табличку на 19:02 можно добавить третий столбец: Initial Declaration AND Extension, в которой будут 3 прочерка (у структур, классов и NSObject такое невозможно), и Table у протоколов. Тогда она станет исчерпывающей)
Да, идея верная. Но тут скорее взаимное исключение, чем отдельный случай. Если есть определение в протоколе, то будет использоваться Table и в общем-то дальше не важно что в Extension делается
@@MadBrains я понял вашу логику, с ней тоже можно согласиться.
Но вот что интересно: оказывается, компилятор позволяет сделать то же самое (объявить метод в Initial Declaration и Extension одновременно) и для наследников NSObject, тем самым позволяя фактически переопределять методы, не наследуясь, а лишь расширяясь. Что прямо противоречит оф докам по языку свифт. И здравому смыслу, есличес.
Поэтому я настаиваю на дополнительном столбце:) в нем слишком много интересного и противоречивого
20:03 возможно не доступно override так как super.walk вы не вызовите , а без этого нарушение правил Барбары Лисков