Загрузка нескольких версий одного и того же класса

Допустим, я выпускаю библиотеку кода как отдельный класс PHP. Затем кто-то использует версию 1.0 этой библиотеки в своем приложении. Позже я выпускаю версию библиотеки 2.0, и этому же кому-то по какой-либо причине необходимо использовать и 1.0, и 2.0 параллельно в своем приложении, потому что либо он, либо я нарушили обратную совместимость с новым выпуском.

имена классов разные, это ' Достаточно легко включить и создать и то, и другое, потому что нет конфликта имен. Но если имена классов остаются неизменными, мы сталкиваемся с проблемами:

include /lib/api-1.0/library.php;
$oldlibary = new Library();

include /lib/api-2.0/library.php;
$newlibrary = new Library();

Это просто не сработает, потому что мы не можем загрузить два класса с именем Библиотека . Другой разработчик предложил альтернативу использованию пространств имен. Следующее должно работать:

namespace old {
    include /lib/api-1.0/library.php;
}
namespace new {
    include /lib/api-2.0/library.php;
}

$oldlibary = new old\Library();
$newlibrary = new new\Library();

К сожалению, это не очень масштабируемое. Он будет работать с ситуацией с двумя экземплярами (которые, надеюсь, мне не пришлось бы использовать в первую очередь), но для масштабирования до 3, 4, 5 или более экземпляров вам нужно будет определить дополнительные пространства имен и настройте, если вы не используете эти пространства имен в первую очередь, это куча ненужного кода.

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

Позвольте мне добавить еще несколько пояснений ...

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

Пример использования, который я пытаюсь для работы - это модуль, в котором конечный пользователь устанавливает два разных модуля от двух разных разработчиков: назовите их Apple и Orange . Оба модуля используют версию 1.0 моей библиотеки, и это здорово. Мы можем создать его экземпляр один раз , и оба набора кода могут извлечь выгоду из этой функциональности.

Позже, Я выпускаю небольшой патч для этой библиотеки. Он имеет версию 1.1, потому что не нарушает обратную совместимость с веткой 1.x. Разработчик Apple немедленно обновляет свою локальную версию и выпускает новую версию своей системы. Разработчик Orange находится в отпуске и не беспокоит.

Когда конечный пользователь обновляет Apple , она получает последнюю отладочную версию моей библиотеки. Поскольку это служебный выпуск, предполагается, что полная замена версии 1.0 безопасна. Таким образом, код инстанцирует только 1.1, и Orange извлекает выгоду из исправления обслуживания, хотя разработчик никогда не удосужился обновить свой выпуск.

Даже позже я решил обновить свой API, чтобы добавить некоторые хуки в Facebook для некоторых причина. Новые функции и расширения API сильно меняют библиотеку, поэтому я обновил версию до 2.0, чтобы пометить ее как потенциально несовместимую с предыдущими версиями во всех ситуациях. И снова Apple входит и обновляет свой код. Ничего не сломалось, он просто заменил мою библиотеку в своей папке / lib на последнюю версию. Оранжевый решил вернуться в школу, чтобы стать клоуном, но прекратил поддержку своего модуля, поэтому он не получает никаких обновлений.

Когда конечный пользователь обновляет Apple с новым выпуском она автоматически получает версию 2.0 моей библиотеки. Но Orange имел код в своей системе, который уже добавлял хуки Facebook, поэтому возникнет конфликт, если 2.0 будет добавлен в его библиотеку по умолчанию. Поэтому вместо полной замены я создаю экземпляр 2. 0 один раз для Apple и параллельно создать экземпляр версии 1.0, поставляемой с Orange , чтобы он мог использовать правильный код.

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