Почему внутренние классы появляются в ProductName-Swift.h? Могу ли я изменить этот файл вручную?

Я создаю фреймворк Swift, который зависит от другого фреймворка Objective C (поэтому проект содержит заголовочный файл моста). Когда я открываю автоматически сгенерированный файл ProductName-Swift.h внутри заголовков моей структуры, я вижу классы, которые я не хотел бы раскрывать (с внутренним модификатором). Согласно документам Apple, это законно:

По умолчанию сгенерированный заголовок содержит интерфейсы для объявлений Swift, помеченные модификатором public или open. Если у вашего целевого приложения есть соединительный заголовок Objective-C, сгенерированный заголовок также включает интерфейсы, помеченные модификатором internal.

Но почему это происходит? Может кто-нибудь объяснить мне, пожалуйста? Согласно моей логике, если я решу сделать какой-то код внутренним, его нельзя использовать за пределами моего фреймворка и не следует показывать в заголовке.

В любом случае, я могу написать сценарий bash, который удалит внутренние классы и функции из ProductName-Swift.h после сборки, но я не уверен, что это нормально. Будут ли у пользователя какие-либо проблемы при использовании моей структуры Swift с «фиксированным» ProductName-Swift.h, например, внутри его проекта Objective C?


ios swift objective-c bridging-header
person Boris    schedule 02.07.2019    source источник
comment
Связанный stackoverflow.com /вопросы/53173819/   -  person Cristik    schedule 26.09.2019

Ответы (1)


arrow_upward
1
arrow_downward

Согласно официальной документации Swift SwiftDoc, внутренний модификатор указан как:

Внутренний доступ позволяет использовать сущности в любом исходном файле из определяющего их модуля, но не в любом исходном файле за пределами этого модуля. Обычно вы используете внутренний доступ при определении внутренней структуры приложения или фреймворка.

Теперь, если вы предоставили какой-либо из этих внутренних классов для Objective-C, автоматически созданный соединительный заголовок, вероятно, будет включать определение этого класса.

Потому что Xcode создает связующий заголовок для того, чтобы эти классы Swift можно было использовать из любого исходного файла Obejctive-C, который вы можете добавить/записать в этом проекте.

Если эти классы никогда не будут использоваться из какого-либо файла Objective-C, вы можете попробовать удалить из них @objc (если они уже были выставлены) или поместить модификатор закрытого доступа к файлу.

В этом сценарии, что еще вы можете сделать, так это когда вы создаете фреймворк, вы можете проверить, сохраняется ли автоматически сгенерированный файл заголовка в качестве общедоступного заголовка из настроек фазы сборки Xcode. Если он общедоступный, сделайте его приватным и предоставьте настраиваемый заголовок для пользователей вашей платформы, где вы размещаете только нужные определения классов Swift.

Если он вообще не указан там как заголовок, и если вы решите не использовать эти внутренние классы из каких-либо файлов Objective-C в своей структуре (если вы решите иметь какой-либо файл Objective-C в своем проекте), тогда конечно, вы можете продолжить работу со сценарием, чтобы удалить нежелательные определения классов из этого связующего заголовка.

Надеюсь, это поможет.

person FahimAhmed    schedule 25.08.2019