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

<p>objective-c не имеет пространств имен; это очень похоже на c, все находится в одном глобальном пространстве имен. обычной практикой является добавление классов к инициалам, например если вы работаете в ibm, вы можете поставить перед ними префикс "ibm"; если вы работаете в microsoft, вы можете использовать "ms"; и так далее. иногда инициалы относятся к проекту, например, adium использует префиксы классов с "ai" (так как за этим нет никакой компании, которую вы могли бы взять инициалы). apple префиксирует классы с помощью ns и говорит, что этот префикс зарезервирован только для apple.</p><p>пока все хорошо. но добавление от 2 до 4 букв к имени класса впереди - очень и очень ограниченное пространство имен. например. ms или ai могут иметь совершенно разные значения (например, ai может быть искусственным интеллектом), и некоторые другие разработчики могут решить использовать их и создать класс с одинаковым именем. <em> взрыв </em>, столкновение пространства имен.</p><p>хорошо, если это коллизия между одним из ваших собственных классов и одним из используемых вами внешних фреймворков, вы можете легко изменить наименование вашего класса, не беда. <strong>но что, если вы используете две внешние платформы, обе из которых у вас нет исходного кода и которые вы не можете изменить?</strong> ваше приложение связывается с ними обоими, и вы получаете конфликт имен. как бы вы решили это? каков наилучший способ обойти их таким образом, чтобы вы все еще могли использовать оба класса?</p><p>в c вы можете обойти это, не связываясь напрямую с библиотекой, вместо этого вы загружаете библиотеку во время выполнения, используя dlopen (), затем находите искомый символ с помощью dlsym () и назначаете его глобальному символу (который вы можно назвать как угодно, а затем получить к нему доступ через этот глобальный символ. например. если у вас есть конфликт, потому что в некоторой библиотеке c есть функция с именем open (), вы можете определить переменную с именем myopen и указать ей функцию open () библиотеки, таким образом, когда вы хотите использовать систему open (), вы просто используете open (), а когда вы хотите использовать другой, вы получаете доступ к нему через идентификатор myopen.</p><p>возможно ли что-то подобное в objective-c, и если нет, есть ли какое-нибудь другое умное, хитрое решение, которое вы можете использовать для разрешения конфликтов пространства имен? есть идеи?</p><hr><h3>обновление:</h3><p>просто чтобы прояснить это: ответы, которые предлагают, как избежать столкновений пространства имен заранее или как создать лучшее пространство имен, безусловно, приветствуются; однако я не приму их как <strong>ответ</strong>, поскольку они не решают мою проблему. у меня есть две библиотеки, и их имена классов сталкиваются. я не могу их изменить; у меня нет источника ни того, ни другого. столкновение уже произошло, и советы о том, как его можно было избежать заранее, больше не помогут. я могу направить их разработчикам этих фреймворков и надеюсь, что в будущем они выберут лучшее пространство имен, но сейчас я ищу решение для работы с фреймворками прямо сейчас в одном приложении. какие-нибудь решения, чтобы сделать это возможным?</p>

<p>если вам не нужно использовать классы из обеих платформ одновременно, и вы нацеливаетесь на платформы, поддерживающие выгрузку nsbundle (os x 10.4 или более поздняя версия, без поддержки gnustep), и производительность действительно не является для вас проблемой, я полагаю чтобы вы могли загружать один фреймворк каждый раз, когда вам нужно использовать класс из него, а затем выгружать его и загружать другой, когда вам нужно использовать другой фреймворк.</p><p>моя первоначальная идея состояла в том, чтобы использовать nsbundle для загрузки одной из платформ, затем скопировать или переименовать классы в этой платформе, а затем загрузить другую платформу. есть две проблемы с этим. во-первых, я не смог найти функцию для копирования данных, указанных для переименования или копирования класса, и любые другие классы в этом первом каркасе, которые ссылаются на переименованный класс, теперь будут ссылаться на класс из другого каркаса.</p><p>вам не нужно было бы копировать или переименовывать класс, если бы был способ скопировать данные, на которые указывает imp. вы можете создать новый класс, а затем скопировать ivars, методы, свойства и категории. гораздо больше работы, но это возможно. однако у вас все равно будет проблема с другими классами в рамках, ссылающимися на неправильный класс.</p><p>правка: принципиальное различие между средами выполнения c и objective-c, насколько я понимаю, при загрузке библиотек функции в этих библиотеках содержат указатели на любые символы, на которые они ссылаются, тогда как в objective-c они содержат строковые представления названия этих символов. таким образом, в вашем примере вы можете использовать dlsym, чтобы получить адрес символа в памяти и прикрепить его к другому символу. другой код в библиотеке все еще работает, потому что вы не меняете адрес исходного символа. objective-c использует таблицу соответствия для сопоставления имен классов с адресами, и это сопоставление 1-1, поэтому у вас не может быть двух классов с одинаковым именем. таким образом, чтобы загрузить оба класса, один из них должен изменить свое имя. однако, когда другим классам требуется доступ к одному из классов с этим именем, они будут запрашивать у таблицы поиска его адрес, и таблица поиска никогда не будет возвращать адрес переименованного класса, учитывая имя исходного класса.</p>

<p>префикс ваших классов с уникальным префиксом является принципиально единственным вариантом, но есть несколько способов сделать это менее обременительным и уродливым. существует долгое обсуждение вариантов <a href="http://www.cocoadev.com/index.pl?alternativestoprefixing">здесь</a> . моя любимая - это директива компилятора objective-c <code>@compatibility\_alias</code> (описанная <a href="http://developer.apple.com/library/mac/#documentation/developertools/gcc-4.0.1/gcc/compatibility\_005falias.html">здесь</a> ). вы можете использовать <code>@compatibility\_alias</code>, чтобы "переименовать" класс, что позволит вам назвать свой класс, используя полное доменное имя или некоторый такой префикс:</p><pre><code>@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 </code></pre><p>как часть полной стратегии, вы можете добавить к своим классам префикс с уникальным префиксом, таким как полное доменное имя, а затем создать заголовок со всем <code>@compatibility\_alias</code> (я думаю, вы можете автоматически сгенерировать указанный заголовок).</p><p>недостаток префикса, подобного этому, заключается в том, что вы должны вводить истинное имя класса (например, <code>com\_whatever\_classname</code> выше) во все, что требует имя класса из строки, кроме компилятора. в частности, <code>@compatibility\_alias</code> - это директива компилятора, а не функция времени выполнения, поэтому <code>nsclassfromstring(classname)</code> завершится с ошибкой (вернет <code>nil</code>) - вам придется использовать <code>nsclassfromstring(com\_whaterver\_classname)</code>. вы можете использовать <code>ibtool</code> через фазу сборки, чтобы изменить имена классов в интерфейсном разработчике nib/xib так, чтобы вам не приходилось писать полный com\_whatever \_... в интерфейсном разработчике.</p><p>последнее замечание: поскольку это директива компилятора (и в то же время неясная), она может не переноситься между компиляторами. в частности, я не знаю, работает ли он с внешним интерфейсом clang из проекта llvm, хотя он должен работать с llvm-gcc (llvm с использованием внешнего интерфейса gcc).</p>

<p>несколько человек уже поделились некоторым хитрым и умным кодом, который может помочь решить проблему. некоторые из предложений могут работать, но все они не идеальны, а некоторые из них просто противны для реализации. (иногда уродливые хаки неизбежны, но я стараюсь избегать их всякий раз, когда могу.) с практической точки зрения, вот мои предложения.</p><ol> <li>в любом случае проинформируйте разработчиков о <strong> обеих </strong> структурах конфликта и дайте понять, что их неспособность избежать и/или справиться с ним вызывает у вас реальные бизнес-проблемы, которые могут привести к потере доходов от бизнеса, если их не решить. подчеркните, что хотя разрешение существующих конфликтов для каждого класса является менее навязчивым решением, полное изменение их префикса (или использование одного префикса, если их нет, и позор им!) - лучший способ гарантировать, что они не будут увидеть ту же проблему снова.</li> <li>если конфликты имен ограничены разумно небольшим набором классов, посмотрите, сможете ли вы обойти только эти классы, особенно если один из конфликтующих классов не используется вашим кодом, прямо или косвенно. если так, посмотрите, предоставит ли поставщик специальную версию платформы, которая не включает конфликтующие классы. если нет, то будьте откровенны с тем фактом, что их негибкость снижает вашу рентабельность от использования их инфраструктуры. не расстраивайтесь из-за настойчивости в рассудке - клиент всегда прав. ;-)</li> <li>если один фреймворк является более "необязательным", вы можете подумать о его замене другим фреймворком (или комбинацией кода), либо сторонним, либо доморощенным. (последнее является нежелательным наихудшим случаем, поскольку оно, безусловно, повлечет за собой дополнительные бизнес-затраты, как на разработку, так и на сопровождение.) если вы это сделаете, сообщите поставщику этой платформы именно то, почему вы решили не использовать их среду.</li> <li>если обе платформы считаются одинаково необходимыми для вашего приложения, изучите способы выделить использование одного из них в один или несколько отдельных процессов, возможно, через do, как предложил луи гербарг. в зависимости от степени общения, это может быть не так плохо, как вы могли ожидать. несколько программ (включая quicktime, я полагаю) используют этот подход для обеспечения более детальной безопасности, обеспечиваемой с помощью <a href="http://www.318.com/techjournal/security/a-brief-introduction-to-mac-os-x-sandbox-technology/">профили песочницы seatbelt в leopard</a> , так что только определенному подмножеству вашего кода разрешено выполнять критические или конфиденциальные операции. , производительность будет компромиссом, но может быть вашим единственным вариантом</li> </ol><p>я предполагаю, что лицензионные сборы, сроки и сроки могут помешать мгновенному действию по любому из этих пунктов. надеюсь, вы сможете решить конфликт как можно скорее. удачи!</p>

<p>это грубое значение, но вы можете использовать <a href="http://developer.apple.com/documentation/cocoa/conceptual/distrobjects/distrobjects.html">распределенные объекты</a> , чтобы сохранить один из классов только в адресе подчиненных программ и rpc для него. это может привести к путанице, если вы передадите кучу вещей туда-сюда (и может оказаться невозможным, если оба класса напрямую манипулируют представлениями и т.д.).</p><p>есть и другие потенциальные решения, но многие из них зависят от конкретной ситуации. в частности, используете ли вы современную или унаследованную среду выполнения, толстую или однократную, 32- или 64-разрядную архитектуру, на какие версии ос вы нацеливаетесь, динамически, статически или у вас есть выбор, и есть ли у вас такой выбор? хорошо, чтобы сделать что-то, что может потребовать обслуживания для новых обновлений программного обеспечения.</p><p>если вы действительно в отчаянии, то вы можете сделать следующее:</p><ol> <li>не ссылаться на одну из библиотек напрямую</li> <li>реализуйте альтернативную версию подпрограмм времени выполнения objc, которая меняет имя во время загрузки (ознакомьтесь с проектом <a href="http://www.opensource.apple.com/darwinsource/10.5.6/objc4-371.2/runtime/">objc4</a> , что именно вам нужно сделать, зависит от ряда вопросов, которые я задавал выше, но это должно быть возможно независимо от того, каковы ответы).</li> <li>используйте что-то вроде <a href="http://guiheneuf.org/mach%20inject%20for%20intel.html">mach\_override</a> , чтобы внедрить вашу новую реализацию</li> <li>загрузите новую библиотеку, используя обычные методы, она пройдет процедуру пропатченного компоновщика и изменит ее classname</li> </ol><p>вышеперечисленное будет довольно трудоемким, и если вам нужно реализовать его для нескольких арок и разных версий времени выполнения, это будет очень неприятно, но определенно можно заставить работать.</p>

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

<p>отчаянные ситуации требуют отчаянных мер. рассматривали ли вы возможность взлома объектного кода (или файла библиотеки) одной из библиотек, замены символа столкновения на альтернативное имя - такой же длины, но с разным написанием (но, рекомендации, той же длины имени)? по своей сути противный.</p><p>не ясно, вызывает ли ваш код две функции с одинаковым именем, но разными реализациями, или конфликт является косвенным (и неясно, имеет ли он какое-либо значение). однако, по крайней мере, есть шанс, что переименование сработает. также может быть идея минимизировать разницу в написании, чтобы, если символы в таблице были отсортированы в отсортированном порядке, переименование не нарушало порядок. такие вещи, как бинарный поиск, расстраиваются, если массив, который они ищут, находится не в порядке сортировки, как ожидалось.</p>

<p><code>@compatibility\_alias</code> сможет решать конфликты пространства имен класса, например,.</p><pre><code>@compatibility\_alias newaliasclass originalclass; </code></pre><p>однако <strong> это не разрешит ни одно из перечислений, typedefs или коллизий пространства имен протокола </strong>. кроме того, он не очень хорошо работает с <code>@class</code> forward decls исходного класса. поскольку большинство фреймворков будут поставляться с такими не относящимися к классу вещами, как typedefs, вы, скорее всего, не сможете исправить проблему с пространством имен только с compatibility\_alias.</p><p>я посмотрел на <a href="http://michaelchinen.com/2013/12/25/namespacing-a-framework-in-objective-c-compatibility\_alias-and-defines/">проблема, похожая на вашу</a> , но у меня был доступ к источнику, и я строил фреймворки. лучшее решение, которое я нашел для этого, было условное использование <code>@compatibility\_alias</code> с #defines для поддержки enums/typedefs/protocol/etc. вы можете сделать это условно на модуле компиляции для рассматриваемого заголовка, чтобы минимизировать риск расширения содержимого в другой конфликтующей структуре.</p>

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

<p>просто мысль ... не проверенная или не проверенная и может быть отличительной чертой, но вы рассматривали возможность написания адаптера для класса, который вы используете, от более простых платформ ... или, по крайней мере, их интерфейсов?</p><p>если бы вы написали обертку вокруг более простых фреймворков (или того, кто имеет интерфейс, к которому вы обращаетесь меньше всего), было бы невозможно скомпилировать эту обертку в библиотеку. поскольку библиотека предварительно скомпилирована и необходимо распространять только <strong>ее</strong> заголовки, вы бы эффективно скрывали базовый фреймворк и могли бы свободно объединить его со вторым фреймворком с помощью коллизий.</p><p>я, конечно, ценю, что могут быть моменты, когда вам нужно использовать классы из обеих платформ одновременно, однако вы можете предоставить фабрики для дополнительных адаптеров классов этой платформы. в конце этого пункта, я думаю, вам понадобится немного рефакторинга, чтобы извлечь интерфейсы, которые вы используете из обеих платформ, что должно обеспечить хорошую отправную точку для создания вашей оболочки.</p><p>вы можете использовать библиотеку как вам и когда вам понадобится дополнительная функциональность из обернутой библиотеки, и просто перекомпилировать ее, когда она изменится.</p><p>опять же, никоим образом не доказано, но хотелось добавить перспективу. надеюсь, поможет :)</p>

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

<p>префикс файлов - самое простое из известных мне решений. cocoadev имеет страницу пространства имен, которая является попыткой сообщества избежать конфликтов пространства имен. не стесняйтесь добавлять свои собственные в этот список, я считаю, что именно для этого.</p><p> <a href="http://www.cocoadev.com/index.pl?chooseyourownprefix">http://www.cocoadev.com/index.pl?chooseyourownprefix</a> </p>

<p>если столкновение происходит только на уровне статической связи, вы можете выбрать, какая библиотека используется для разрешения символов:</p><pre><code>cc foo.o -ldog bar.o -lcat </code></pre><p>если <code>foo.o</code> и <code>bar.o</code> оба ссылаются на символ <code>rat</code>, тогда <code>libdog</code> разрешит <code>foo.o</code> <code>rat</code>, а <code>libcat</code> разрешит <code>bar.o</code> <code>rat</code>.</p>