Несколько копий объектов под разными неймспейсами

Int_20h

Новичок
Хочу в свой проект с определенной объектной моделью интегрировать шаблонизатор Twig. Но так, чтобы он, в случае чего, не не конфликтовал с еще одной копией Twig'а если вдруг кто-то добавит мой проект к своему в котором также используется Twig.

Для того чтобы это сделать, нужно разместить Twig в своем namespace'е (допустим от называется MyProject) и вызывать его через \MyProject\Twig. Можно ли это как-то прописать не трогая файлов самого шаблонизатора? Очень хочется в дальнейшем обновлять его через менеджер пакетов без ручной правки кода.

Сейчас классы twig'а выглядят так:

=================================================
<?php
class Twig_Autoloader
{
public static function register()
{
ini_set('unserialize_callback_func', 'spl_autoload_call');
spl_autoload_register(array(new self, 'autoload'));
}
=================================================

Т.е. он, во-первых, размещается в глобальном namespace'е, а во-вторых, имеет свой автолоадер, что осложняет дело. Подкиньте какие-нибудь идеи, пожалуйста. Куда копать?
 

AnrDaemon

Продвинутый новичок
Копать в сторону "не занимайся ХХХнёй."
Не может быть двух копий твига, именно из-за неймспейса.
 

Int_20h

Новичок
Не такая уж это и XXXня. Поскольку версии меняются, какие-то функции меняют свои параметры, какие-то становятся deprecated. И когда-нибудь выйдет версия 2.0.

Я ее в в своем проекте обновлю, а какая-нибудь CMS на тот момент продолжит использовать текущую 1.24. В результате набор функций будет разный и совместно использовать один класс они не смогут. Поэтому кажется логичным упаковать свой Twig в свой же namespace, чтобы обеспечить полную совместимость с чужим ПО. Так что вопрос вполне актуален, но пока я вижу способ только в форке Twig'а и прописывании своего неймспейса.
 

Вурдалак

Продвинутый новичок
В общем случае в PHP-проекте не может быть одновременно несколько версий одной и той же зависимости, это известная проблема.
Ты просто через Composer явно декларируешь список поддерживаемых версий Twig, и если другой проект конфликтует с твоим, то Composer сообщит о конфликте.

И когда-нибудь выйдет версия 2.0.
Если речь про Twig, то уже: http://symfony.com/blog/twig-how-to-upgrade-to-2-0-deprecation-notices-to-the-rescue

Если это действительно становится проблемой, то можно поступить следующим образом:
1. Устранить явную зависимость своего проекта от проблемной библиотеки, используя свои интерфейсы.
2. Реализацию этих интерфейсов вынести в отдельный проект. В рамках этого проекта будет несколько версий, каждая из которых будет соответствовать какой-то версии той самой проблемной библиотеки, т.е. одна версия будет работать с Twig 1.24, а другая — с 2.x. Каждая из версий, соответственно, будет требовать свою версию Twig'а.
3. В composer.json основного проекта указать зависимость от проекта из пункта 2, но не фиксированную.

Если какая-то CMS будет в зависимостях указывать твой проект, то Composer отрезолвит именно ту версию реализации из пункта 2, которая не конфликтует с зависимостями этой CMS.
 

Int_20h

Новичок
В общем случае в PHP-проекте не может быть одновременно несколько версий одной и той же зависимости, это известная проблема.
Ты просто через Composer явно декларируешь список поддерживаемых версий Twig, и если другой проект конфликтует с твоим, то Composer сообщит о конфликте.
...
Если какая-то CMS будет в зависимостях указывать твой проект, то Composer отрезолвит именно ту версию реализации из пункта 2, которая не конфликтует с зависимостями этой CMS.
Очень полезный ответ. Все четко и по-существу. Спасибо.
 
Сверху