Каков наилучший способ решить коллизию пространства имен Objective C?
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, и если нет, есть ли какое-нибудь другое умное, хитрое решение, которое вы можете использовать для разрешения конфликтов пространства имен? Есть идеи?
Обновить:
Просто чтобы прояснить это: ответы, которые предлагают, как избежать конфликтов пространства имен заранее или как создать лучшее пространство имен, безусловно, приветствуются; однако я не приму их в качестве ответа, поскольку они не решают мою проблему. У меня есть две библиотеки, и их имена классов сталкиваются. Я не могу их изменить; У меня нет источника ни того, ни другого. Столкновение уже произошло, и советы о том, как его можно было избежать заранее, больше не помогут. Я могу направить их разработчикам этих фреймворков и надеюсь, что в будущем они выберут лучшее пространство имен, но сейчас я ищу решение для работы с фреймворками прямо сейчас в одном приложении. Какие-нибудь решения, чтобы сделать это возможным?
13 ответов
Если вам не нужно использовать классы из обеих платформ одновременно, и вы нацеливаетесь на платформы, поддерживающие выгрузку NSBundle (OS X 10.4 или более поздняя версия, без поддержки GNUStep), и производительность действительно не является для вас проблемой, я полагаю чтобы вы могли загружать один фреймворк каждый раз, когда вам нужно использовать класс из него, а затем выгружать его и загружать другой, когда вам нужно использовать другой фреймворк.
Моя первоначальная идея состояла в том, чтобы использовать NSBundle для загрузки одной из платформ, затем скопировать или переименовать классы в этой платформе, а затем загрузить другую платформу. Есть две проблемы с этим. Во-первых, я не смог найти функцию для копирования данных, указанных для переименования или копирования класса, и любые другие классы в этом первом каркасе, которые ссылаются на переименованный класс, теперь будут ссылаться на класс из другого каркаса.
Вам не нужно было бы копировать или переименовывать класс, если бы был способ скопировать данные, на которые указывает IMP. Вы можете создать новый класс, а затем скопировать ivars, методы, свойства и категории. Гораздо больше работы, но это возможно. Однако у вас все равно будут проблемы с другими классами в рамках, ссылающимися на неправильный класс.
РЕДАКТИРОВАТЬ: Принципиальное различие между средами выполнения C и Objective-C, насколько я понимаю, при загрузке библиотек функции в этих библиотеках содержат указатели на любые символы, на которые они ссылаются, тогда как в Objective-C они содержат строковые представления названия этих символов. Таким образом, в вашем примере вы можете использовать dlsym, чтобы получить адрес символа в памяти и прикрепить его к другому символу. Другой код в библиотеке все еще работает, потому что вы не меняете адрес исходного символа. Objective-C использует таблицу соответствия для сопоставления имен классов с адресами, и это отображение 1-1, поэтому у вас не может быть двух классов с одинаковым именем. Таким образом, чтобы загрузить оба класса, один из них должен изменить свое имя. Однако, когда другим классам требуется доступ к одному из классов с этим именем, они будут запрашивать у таблицы поиска его адрес, и таблица поиска никогда не будет возвращать адрес переименованного класса, учитывая имя исходного класса.
Префикс ваших классов с уникальным префиксом является принципиально единственным вариантом, но есть несколько способов сделать это менее обременительным и уродливым. Здесь долгое обсуждение вариантов. Мой любимый это @compatibility_alias Директива компилятора Objective-C (описана здесь). Ты можешь использовать @compatibility_alias "переименовать" класс, позволяя вам назвать его класс, используя FQDN или такой префикс:
@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
Как часть полной стратегии, вы можете добавить к своим классам префикс с уникальным префиксом, таким как полное доменное имя, а затем создать заголовок со всеми @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).
Несколько человек уже поделились некоторым хитрым и умным кодом, который может помочь решить проблему. Некоторые из предложений могут работать, но все они не идеальны, а некоторые из них просто противны для реализации. (Иногда уродливые хаки неизбежны, но я стараюсь избегать их всякий раз, когда могу.) С практической точки зрения, вот мои предложения.
- В любом случае проинформируйте разработчиков обеих платформ о конфликте и дайте понять, что их неспособность избежать и / или справиться с ним вызывает у вас реальные бизнес-проблемы, которые могут привести к потере доходов от бизнеса, если их не решить. Подчеркните, что хотя разрешение существующих конфликтов для каждого класса является менее навязчивым решением, полное изменение их префикса (или использование одного префикса, если их нет, и позор им!) - лучший способ гарантировать, что они не будут увидеть ту же проблему снова.
- Если конфликты имен ограничены разумно небольшим набором классов, посмотрите, сможете ли вы обойти только эти классы, особенно если один из конфликтующих классов не используется вашим кодом, прямо или косвенно. Если так, посмотрите, предоставит ли поставщик специальную версию платформы, которая не включает конфликтующие классы. Если нет, то будьте откровенны с тем фактом, что их негибкость снижает вашу рентабельность от использования их инфраструктуры. Не расстраивайтесь из-за настойчивости в рассудке - клиент всегда прав.;-)
- Если один фреймворк является более "необязательным", вы можете подумать о его замене другим фреймворком (или комбинацией кода), либо сторонним, либо доморощенным. (Последнее является нежелательным наихудшим случаем, так как оно, безусловно, повлечет за собой дополнительные бизнес-затраты, как на разработку, так и на обслуживание.) Если вы это сделаете, сообщите поставщику этой платформы именно то, почему вы решили не использовать их среду.
- Если обе платформы считаются одинаково необходимыми для вашего приложения, изучите способы выделить использование одного из них в один или несколько отдельных процессов, возможно, через DO, как предложил Луи Гербарг. В зависимости от степени общения, это может быть не так плохо, как вы могли ожидать. Несколько программ (включая QuickTime, я полагаю) используют этот подход для обеспечения более детальной безопасности, обеспечиваемой использованием профилей песочницы Seatbelt в Leopard, так что только определенному подмножеству вашего кода разрешено выполнять критические или важные операции. Производительность будет компромиссом, но может быть вашим единственным вариантом
Я предполагаю, что лицензионные сборы, сроки и сроки могут помешать мгновенному действию по любому из этих пунктов. Надеюсь, вы сможете решить конфликт как можно скорее. Удачи!
Это грубо, но вы можете использовать распределенные объекты, чтобы сохранить один из классов только по адресу подчиненных программ и RPC к нему. Это может стать беспорядочным, если вы передадите кучу вещей туда-сюда (и может оказаться невозможным, если оба класса напрямую манипулируют представлениями и т. Д.).
Есть и другие потенциальные решения, но многие из них зависят от конкретной ситуации. В частности, используете ли вы современную или унаследованную среду выполнения, у вас полнофункциональная или одиночная архитектура, 32 или 64-разрядная, на какие версии ОС вы нацеливаетесь, динамически, статически или у вас есть выбор, и есть ли у вас такой выбор? хорошо, чтобы сделать что-то, что может потребовать обслуживания для новых обновлений программного обеспечения.
Если вы действительно в отчаянии, то вы можете сделать следующее:
- Не ссылаться на одну из библиотек напрямую
- Реализуйте альтернативную версию подпрограмм времени выполнения objc, которая изменяет имя во время загрузки ( ознакомьтесь с проектом objc4, что именно вам нужно сделать, зависит от ряда вопросов, которые я задавал выше, но это должно быть возможно независимо от того, какие ответы).
- Используйте что-то вроде mach_override, чтобы внедрить вашу новую реализацию
- Загрузите новую библиотеку, используя обычные методы, она пройдет процедуру пропатченного компоновщика и изменит ее className
Вышеприведенное будет довольно трудоемким, и если вам нужно реализовать его для нескольких арок и разных версий времени выполнения, это будет очень неприятно, но определенно можно заставить работать.
Рассматривали ли вы вопрос об использовании функций времени выполнения (/usr/include/objc/runtime.h) для клонирования одного из конфликтующих классов в неколлизирующий класс, а затем загрузки структуры сталкивающихся классов? (это потребовало бы загрузки конфликтующих структур для загрузки в разное время.)
Вы можете проверять классы ivars, методы (с именами и адресами реализации) и имена в среде выполнения, а также динамически создавать свои собственные, чтобы иметь одинаковый макет ivar, имена методов / адреса реализации и отличаться только по имени (чтобы избежать столкновение)
Отчаянные ситуации требуют отчаянных мер. Рассматривали ли вы возможность взлома объектного кода (или файла библиотеки) одной из библиотек, замены символа столкновения на альтернативное имя - такой же длины, но с разным написанием (но, рекомендация, той же длины имени)? По своей сути противный.
Не ясно, вызывает ли ваш код две функции с одинаковым именем, но разными реализациями, или конфликт является косвенным (и неясно, имеет ли он какое-либо значение). Однако, по крайней мере, есть шанс, что переименование сработает. Также может оказаться идеей минимизировать разницу в написании, чтобы, если символы в таблице были отсортированы в отсортированном порядке, переименование не приводило к нарушению порядка. Такие вещи, как бинарный поиск, расстраиваются, если массив, который они ищут, находится не в порядке сортировки, как ожидалось.
@compatibility_alias сможет решать конфликты пространства имен класса, например
@compatibility_alias NewAliasClass OriginalClass;
Однако это не разрешит ни одно из перечислений, typedefs или конфликтов пространства имен протокола. Кроме того, это не очень хорошо с @class вперед decls оригинального класса. Поскольку большинство фреймворков будут поставляться с такими не относящимися к классу вещами, как typedefs, вы, скорее всего, не сможете исправить проблему с пространством имен только с compatibility_alias.
Я посмотрел на проблему, похожую на вашу, но у меня был доступ к источнику, и я строил фреймворки. Лучшее решение, которое я нашел для этого, использовало @compatibility_alias условно с #defines для поддержки enums/typedefs/protocol /etc. Вы можете сделать это условно на модуле компиляции для рассматриваемого заголовка, чтобы минимизировать риск расширения содержимого в другой конфликтующей среде.
Кажется, проблема в том, что вы не можете ссылаться на файлы заголовков из обеих систем в одном и том же модуле перевода (исходный файл). Если вы создаете обертки target-c вокруг библиотек (делая их более пригодными для использования в процессе), и только #include заголовки для каждой библиотеки в реализации классов-оболочек, это будет эффективно разделять конфликты имен.
У меня недостаточно опыта с этим в target-c (только начало работы), но я верю, что именно это я и сделал бы в C.
Если у вас возникла коллизия, я бы посоветовал вам подумать о том, как вы могли бы реорганизовать одну из платформ вашего приложения. Наличие коллизии говорит о том, что они делают схожие вещи, как есть, и вы, вероятно, можете обойтись с помощью дополнительной инфраструктуры просто путем рефакторинга вашего приложения. Это не только решит вашу проблему с пространством имен, но и сделает ваш код более надежным, простым в обслуживании и более эффективным.
За более техническое решение, если бы я был на вашем месте, это был бы мой выбор.
Просто мысль... не проверенная или не проверенная и может быть отличительной чертой, но вы рассматривали возможность написания адаптера для класса, который вы используете, от более простых платформ... или, по крайней мере, их интерфейсов?
Если бы вы написали обертку вокруг более простых фреймворков (или того, кто имеет интерфейс, к которому вы обращаетесь меньше всего), было бы невозможно скомпилировать эту обертку в библиотеку. Поскольку библиотека предварительно скомпилирована, и нужно распределять только ее заголовки, вы бы эффективно скрывали базовый фреймворк и могли бы свободно сочетать его со вторым фреймворком с помощью столкновения.
Я, конечно, понимаю, что могут быть моменты, когда вам нужно использовать классы из обеих платформ одновременно, однако вы можете предоставить фабрики для дополнительных адаптеров классов этой платформы. В конце этого пункта, я думаю, вам понадобится немного рефакторинга, чтобы извлечь интерфейсы, которые вы используете из обеих платформ, что должно послужить хорошей отправной точкой для создания вашей оболочки.
Вы можете использовать библиотеку так, как вам и когда вам потребуется дополнительная функциональность из обернутой библиотеки, и просто перекомпилировать ее, когда она изменится.
Опять же, никоим образом не доказано, но хотелось добавить перспективу. Надеюсь, поможет:)
Префикс файлов - самое простое из известных мне решений. Cocoadev имеет страницу пространства имен, которая является попыткой сообщества избежать конфликтов пространства имен. Не стесняйтесь добавлять свои собственные в этот список, я считаю, что именно для этого.
Если столкновение происходит только на уровне статической связи, вы можете выбрать, какая библиотека используется для разрешения символов:
cc foo.o -ldog bar.o -lcat
Если foo.o а также bar.o оба ссылаются на символ rat затем libdog разрешит foo.o"s rat а также libcat разрешит bar.o"s rat,
Если у вас есть две фреймворки с одинаковым именем функции, вы можете попробовать динамически загрузить фреймворки. Это будет не элегантно, но возможно. Как это сделать с классами Objective-C, я не знаю. Я угадываю NSBundle Класс будет иметь методы, которые будут загружать определенный класс.