Каков наилучший способ решить коллизию пространства имен Objective C?

Question

Objective-C не имеет пространств имен; это очень похоже на C, все находится в одном глобальном пространстве имен. Обычной практикой является добавление классов к инициалам, например если вы работаете в IBM, вы можете поставить перед ними префикс «IBM»; если вы работаете в Microsoft, вы можете использовать «MS»; и так далее. Иногда инициалы относятся к проекту, например, Adium использует префиксы классов с "AI" (так как за этим нет никакой компании, которую вы могли бы взять инициалы). Apple префиксирует классы с NS и говорит, что этот префикс зарезервирован только для Apple.

Пока все хорошо. Но добавление от 2 до 4 букв к имени класса впереди - очень и очень ограниченное пространство имен. Например. MS или AI могут иметь совершенно разные значения (например, AI может быть искусственным интеллектом), и некоторые другие разработчики могут решить использовать их и создать класс с одинаковым именем. Взрыв , столкновение пространства имен.

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

В C вы можете обойти это, не связываясь напрямую с библиотекой, вместо этого вы загружаете библиотеку во время выполнения, используя dlopen (), затем находите искомый символ с помощью dlsym () и назначаете его глобальному символу. (что вы можете назвать как угодно), а затем получить к нему доступ через этот глобальный символ. Например. если у вас есть конфликт, потому что в некоторой библиотеке C есть функция с именем open (), вы можете определить переменную с именем myOpen и указать ей функцию open () библиотеки, таким образом, когда вы хотите использовать систему open (), вы просто используете open (), а когда вы хотите использовать другой, вы получаете к нему доступ через идентификатор myOpen.

Возможно ли нечто подобное в Objective-C, а если нет, то есть ли какое-нибудь другое умное, хитрое решение, которое вы можете использовать для разрешения конфликтов пространства имен? Есть идеи?

---

Обновление:

Просто чтобы прояснить это: ответы, которые предлагают, как избежать конфликтов пространства имен заранее или как создать лучшее пространство имен, безусловно, приветствуются; однако я не приму их как ответ , поскольку они не решают мою проблему. У меня есть две библиотеки, и их имена классов сталкиваются. Я не могу их изменить; У меня нет источника ни того, ни другого. Столкновение уже произошло, и советы о том, как его можно было избежать заранее, больше не помогут. Я могу направить их разработчикам этих фреймворков и надеюсь, что в будущем они выберут лучшее пространство имен, но сейчас я ищу решение для работы с фреймворками прямо сейчас в одном приложении. Какие-нибудь решения, чтобы сделать это возможным?

Answer 1

Префикс ваших классов с уникальным префиксом является принципиально единственным вариантом, но есть несколько способов сделать это менее обременительным и уродливым. Здесь долгое обсуждение вариантов здесь . Моим любимым является директива компилятора Objective-C @compatibility_alias (описанная здесь ). Вы можете использовать @compatibility_alias, чтобы «переименовать» класс, позволяя назвать его класс с помощью полного доменного имени или некоторого такого префикса:

@interface COM_WHATEVER_ClassName : NSObject
@end

@compatibility_alias ClassName COM_WHATEVER_ClassName
// now ClassName is an alias for COM_WHATEVER_ClassName

@implementation ClassName //OK
//blah
@end

ClassName *myClass; //OK

Как часть законченной стратегии, вы могли бы поставить перед всеми вашими классами уникальный префикс, такой как FQDN, а затем создать заголовок со всеми @compatibility_alias (я думаю, вы могли бы автоматически генерировать указанный заголовок).

Недостаток префикса, подобного этому, заключается в том, что вы должны вводить истинное имя класса (например, COM_WHATEVER_ClassName выше) во все, что требует имя класса из строки, кроме компилятора. В частности, @compatibility_alias - это директива компилятора, а не функция времени выполнения, поэтому NSClassFromString(ClassName) завершится с ошибкой (вернет nil) - вам придется использовать NSClassFromString(COM_WHATERVER_ClassName). Вы можете использовать ibtool через фазу сборки, чтобы изменить имена классов в Интерфейсном Разработчике nib / xib, чтобы вам не приходилось писать полный COM_WHATEVER _... в Интерфейсном Разработчике.

Последнее предупреждение: поскольку это директива компилятора (и в то же время неясная), она не может быть переносимой между компиляторами. В частности, я не знаю, работает ли он с внешним интерфейсом Clang из проекта LLVM, хотя он должен работать с LLVM-GCC (LLVM с использованием внешнего интерфейса GCC).

Answer 2

Если вам не нужно использовать классы из обеих платформ одновременно, и вы нацеливаетесь на платформы, поддерживающие выгрузку NSBundle (OS X 10.4 или новее, без поддержки GNUStep), и производительность действительно не является для вас проблемой Я считаю, что вы можете загружать один фреймворк каждый раз, когда вам нужно использовать класс из него, а затем выгружать его и загружать другой, когда вам нужно использовать другой фреймворк.

Моя первоначальная идея состояла в том, чтобы использовать NSBundle для загрузки одной из платформ, затем скопировать или переименовать классы в этой платформе, а затем загрузить другую платформу. Есть две проблемы с этим. Во-первых, я не смог найти функцию для копирования данных, указанных для переименования или копирования класса, и любые другие классы в этом первом каркасе, которые ссылаются на переименованный класс, теперь будут ссылаться на класс из другого каркаса.

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

РЕДАКТИРОВАТЬ: принципиальное различие между средами выполнения C и Objective-C, насколько я понимаю, при загрузке библиотек функции в этих библиотеках содержат указатели на любые символы, на которые они ссылаются, тогда как в Objective-C они содержат строку представления имен этих символов. Таким образом, в вашем примере вы можете использовать dlsym, чтобы получить адрес символа в памяти и прикрепить его к другому символу. Другой код в библиотеке все еще работает, потому что вы не меняете адрес исходного символа. Objective-C использует таблицу соответствия для сопоставления имен классов с адресами, и это сопоставление 1-1, поэтому у вас не может быть двух классов с одинаковым именем. Таким образом, чтобы загрузить оба класса, один из них должен изменить свое имя. Однако, когда другим классам необходимо получить доступ к одному из классов с этим именем, они будут запрашивать у таблицы поиска его адрес, и таблица поиска никогда не будет возвращать адрес переименованного класса, учитывая имя исходного класса.

Answer 3

Несколько человек уже поделились некоторым хитрым и умным кодом, который может помочь решить проблему. Некоторые из предложений могут работать, но все они не идеальны, а некоторые из них просто противны для реализации. (Иногда уродливые хаки неизбежны, но я стараюсь избегать их всякий раз, когда могу.) С практической точки зрения вот мои предложения.

1. В любом случае проинформируйте разработчиков о обеих инфраструктурах конфликта и дайте понять, что их неспособность избежать и / или справиться с ним вызывает у вас реальные бизнес-проблемы, которые могут перерасти в потерянные. доходы от бизнеса, если не решены. Подчеркните, что хотя разрешение существующих конфликтов для каждого класса является менее навязчивым решением, полное изменение их префикса (или использование одного префикса, если их нет, и позор им!) - лучший способ гарантировать, что они не будут увидеть ту же проблему снова.
2. Если конфликты имен ограничены разумно небольшим набором классов, посмотрите, можете ли вы работать только с этими классами, особенно если один из конфликтующих классов не используется вашим кодом, прямо или косвенно. Если так, посмотрите, предоставит ли поставщик специальную версию платформы, которая не включает конфликтующие классы. Если нет, то будьте откровенны с тем фактом, что их негибкость снижает вашу рентабельность от использования их инфраструктуры. Не расстраивайтесь из-за настойчивости в рассудке - клиент всегда прав. ; -)
3. Если один фреймворк является более «необязательным», вы можете подумать о его замене другим фреймворком (или комбинацией кода), либо сторонним, либо доморощенным. (Последнее является нежелательным наихудшим случаем, поскольку оно, безусловно, повлечет за собой дополнительные расходы для бизнеса, как на разработку, так и на сопровождение.) Если вы это сделаете, сообщите поставщику этой платформы именно то, почему вы решили не использовать их среду.
4. Если обе платформы считаются одинаково необходимыми для вашего приложения, изучите способы выделить использование одного из них в один или несколько отдельных процессов, возможно, через DO, как предложил Луи Гербарг. В зависимости от степени общения, это может быть не так плохо, как вы могли ожидать. Несколько программ (включая QuickTime, я полагаю) используют этот подход для обеспечения более детальной защиты, обеспечиваемой с помощью профилей песочницы Seatbelt в Leopard , так что только определенному подмножеству вашего кода разрешено выполнять критические или важные операции. Производительность будет компромиссом, но может быть единственным вариантом

Я предполагаю, что лицензионные сборы, сроки и сроки могут помешать мгновенным действиям по любому из этих пунктов. Надеюсь, вы сможете решить конфликт как можно скорее. Удачи!

Answer 4

Это брутто, но вы можете использовать распределенные объекты , чтобы сохранить один из классов только по адресу подчиненных программ и RPC к нему. Это может привести к путанице, если вы передадите кучу вещей туда-сюда (и может оказаться невозможным, если оба класса напрямую манипулируют представлениями и т. Д.).

Существуют и другие потенциальные решения, но многие из них зависят от конкретной ситуации. В частности, используете ли вы современную или унаследованную среду выполнения, толстую или однократную, 32- или 64-разрядную архитектуру, на какие версии ОС вы нацеливаетесь, динамически, статически или у вас есть выбор, и есть ли у вас такой выбор? хорошо, чтобы сделать что-то, что может потребовать обслуживания для новых обновлений программного обеспечения.

Если вы действительно в отчаянии, вы можете сделать следующее:

1. Нет прямой ссылки на одну из библиотек
2. Реализация альтернативной версии подпрограмм времени выполнения objc, которая меняет имя во время загрузки (ознакомьтесь с проектом objc4 , что именно вам нужно сделать, зависит от ряда вопросов, которые я задавал выше, но это должно быть возможно независимо от того, каковы ответы).
3. Используйте что-то вроде mach_override , чтобы внедрить вашу новую реализацию
4. Загрузите новую библиотеку, используя обычные методы, она пройдет процедуру пропатченного компоновщика и изменит ее className

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

Answer 5

Рассматривали ли вы возможность использования функций времени выполнения (/usr/include/objc/runtime.h) для клонирования одного из конфликтующих классов в неколлизирующий класс, а затем загрузки структуры конфликтующих классов? (это потребовало бы загрузки конфликтующих структур для загрузки в разное время.)

Вы можете проверять классы ivars, методы (с именами и адресами реализации) и именами во время выполнения, а также динамически создавать свои собственные, чтобы иметь одинаковый макет ivar, имена методов / адреса реализации и отличаться только по имени ( чтобы избежать столкновения)

Answer 6

Отчаянные ситуации требуют отчаянных мер. Рассматривали ли вы возможность взлома объектного кода (или файла библиотеки) одной из библиотек, замены символа столкновения на альтернативное имя - такой же длины, но с разным написанием (но, рекомендации, той же длины имени)? По своей сути противный.

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

Answer 7

@compatibility_alias сможет решать конфликты пространства имен класса, например,

@compatibility_alias NewAliasClass OriginalClass;

Однако это не разрешит ни одно из перечислений, typedefs или конфликтов пространства имен протокола . Кроме того, он не очень хорошо играет с @class форвард-декалями оригинального класса. Поскольку большинство фреймворков будут поставляться с такими не относящимися к классу вещами, как typedefs, вы, вероятно, не сможете решить проблему с пространством имен только с compatibility_alias.

Я посмотрел на проблему, аналогичную вашей , но у меня был доступ к исходному тексту и я строил фреймворки. Лучшее решение, которое я нашел для этого, было условно использовать @compatibility_alias с #defines для поддержки enums / typedefs / protocol / etc. Вы можете сделать это условно на модуле компиляции для рассматриваемого заголовка, чтобы минимизировать риск расширения содержимого в другой конфликтующей среде.

Answer 8

Кажется, проблема в том, что вы не можете ссылаться на файлы заголовков из обеих систем в одном и том же модуле перевода (исходный файл). Если вы создаете обертки target-c вокруг библиотек (делая их более пригодными для использования в процессе), и только #include заголовки для каждой библиотеки в реализации классов-оболочек, это будет эффективно разделять конфликты имен.

У меня нет достаточного опыта с этим в target-c (только начало), но я верю, что именно это я и сделал бы в C.

Answer 9

Просто мысль ... не проверенная или не проверенная и может быть отличительной чертой, но вы не задумывались над тем, чтобы написать адаптер для класса, который вы используете, из более простых платформ ... или хотя бы их интерфейсов?

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

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

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

Опять же, никоим образом не доказано, но хотелось добавить перспективу. надеюсь, это поможет:)

Answer 10

Если у вас есть две фреймворки с одинаковым именем функции, вы можете попробовать динамически загрузить фреймворки. Это будет не элегантно, но возможно. Как это сделать с классами Objective-C, я не знаю. Я предполагаю, что класс NSBundle будет иметь методы, которые будут загружать определенный класс.