Size: a a a

2020 December 15

SD

Sam D in SwiftBook
Просто делает архив, сохраняет и все
источник

DI

Dmitry Iv. in SwiftBook
Lev Borodin
1) а может есть у кого под рукой материалы про direct dispatch\table dispatch? Можно с dynamic dispatch
Разницу я примерно понимаю
Однако не понимаю почему при всей своей строгой типизации свифту необходима виртуальная таблица методов для классов


2) правильно ли я понимаю, что в частном случае при продовой компиляции, компилятор увидев отсутствие наследование у тех или иных классов автоматом подставит им "final" заставив таким образом юзать static dispatch и заставлять программистов писать везде final при разработке НЕ либы в принципе бессмысленно?
если ГРУБО, то:

при статической в коде у нас будет
вызвать метод по адресу <определенный адрес>
т.е. здесь уже будет зафиксирован адрес метода, другой метод мы вызвать уже не можем

при табличной
получить адрес метода из таблице по индексу, а потом вызвать метод по адресу
а
здесь будет только лишь зафиксирован индекс в таблице, а адрес метода мы будем получать по индексу

таблицы одного семейства объектов одинаковые (то что отнаследовано от родителя понятно), а вот в зависимости от объекта, адреса методов будут меняться, что позволит вызывать метод только того объекта который в данный момент нам предоставлен => полиформизм в действии

2) да, по умолчанию для релиза в настройках стоит режим Whole module, при таком режиме компилятор везде где можно сделает классы финальными что приведет к тому что для методов этого класса будет юзаться static dispatch
источник

LB

Lev Borodin in SwiftBook
Dmitry Iv.
если ГРУБО, то:

при статической в коде у нас будет
вызвать метод по адресу <определенный адрес>
т.е. здесь уже будет зафиксирован адрес метода, другой метод мы вызвать уже не можем

при табличной
получить адрес метода из таблице по индексу, а потом вызвать метод по адресу
а
здесь будет только лишь зафиксирован индекс в таблице, а адрес метода мы будем получать по индексу

таблицы одного семейства объектов одинаковые (то что отнаследовано от родителя понятно), а вот в зависимости от объекта, адреса методов будут меняться, что позволит вызывать метод только того объекта который в данный момент нам предоставлен => полиформизм в действии

2) да, по умолчанию для релиза в настройках стоит режим Whole module, при таком режиме компилятор везде где можно сделает классы финальными что приведет к тому что для методов этого класса будет юзаться static dispatch
по поводу табличной:
таблица статична с момента компиляции или генерируется в рантайме?
Если генерируется в рантайме то почему?

Вопрос намекает на то, что если известен индекс в таблице и сама таблица
почему сразу не проставить адрес функции перейдя на static dispatch?
источник

mm

maxim mironow in SwiftBook
привет всем, может кто подсказать / скинуть туториал, как разбить приложение на модули?
источник

AT

Andrey Torlopov in SwiftBook
maxim mironow
привет всем, может кто подсказать / скинуть туториал, как разбить приложение на модули?
в каком смысле на модули?
источник

mm

maxim mironow in SwiftBook
разбить на подпроекты
источник

AT

Andrey Torlopov in SwiftBook
на подпроекты? или на поды? или на SPM модули? или в рамках одного проекта на модули разбить?
источник

mm

maxim mironow in SwiftBook
в рамках одного проекта на модули разбить?
источник

AT

Andrey Torlopov in SwiftBook
ну логически имею в виду. Вот группа классов решающих одну задачу, вот группа классов решающих другую задачу. Которые можно перетащить в другой проект итп.
источник

AT

Andrey Torlopov in SwiftBook
На подпроекты имеет смысл разбивать (как мне кажется) только в 1 случае. Если эти подпроекты будут переиспользоваться. Ну или если проект настолько большой, что сборку нужно хоть как-то ускорить.

А почему на SPM не хочешь разбить? Это попроще будет.
источник

mm

maxim mironow in SwiftBook
создать проект и вытащить туда все сервисы, чтобы там работали pod'ы
источник

AT

Andrey Torlopov in SwiftBook
=))))))
источник

AT

Andrey Torlopov in SwiftBook
плохая идея как мне кажется.
источник

AT

Andrey Torlopov in SwiftBook
Но! Может кто-то тут так делал и это упростило жизнь?
источник

AT

Andrey Torlopov in SwiftBook
вот что действительно жизнь упрощает - это разбивка дизайна на компоненты (стилизованные) и использование уже их. Плюс разбивка логических единиц на модули (неважно где они будут лежать). И чтобы классы были протоколами закрыты. Тогда это можно переиспользовать и тестировать с минимальными трудозатратами.
источник

DK

Denis Kim in SwiftBook
а если без протоколв то переиспользовать труднее?
источник

mm

maxim mironow in SwiftBook
ну вот мне и нужен модуль для обращения к апи закрытый протоколом
источник

mm

maxim mironow in SwiftBook
чтобы я мог его впихнуть где угодно
источник

AB

Alex Bro in SwiftBook
maxim mironow
ну вот мне и нужен модуль для обращения к апи закрытый протоколом
Создаёшь файл, пишешь там протокол и класс, который имплементирует этот протокол, а в чем у тебя сложность?
источник

AT

Andrey Torlopov in SwiftBook
Denis Kim
а если без протоколв то переиспользовать труднее?
Ну вообще да. Тестировать точно трудней. Просто протокол он более общий. А конкретный класс может иметь название и назначение касаемо твоей предметной области. Поэтому если будешь переиспользовать, то сразу привязываешься к своему классу. А тут протокол и протокол.
источник