Есть задача - нужен загрузчик объектов
Проект полностью описывается по ооп. Есть некий класс sload, входные данные которого есть тип конфигурации (например страница, единичный скрипт, единичное приложение(совокупность объектов)) и путь до конфигурационного файла. Класс получает информацию по алгоритму, описанному в основном ини файле. Грубо говоря, ини файл выступает в роли макроса к основным системным библиотекам. Из ини файла sload получает список объектов, пути до файлов и входные параметры, а также набор инструкций для выполнения с помощью методов sload и загруженных по ини файлу объектов. на основе ини файла строится инклюд список, исполняются инструкции по погашению зависимостей между отдельными объектами.
Вопросы:
1) Что я курил?
2) Как всё это лучше организовать?
3) Посоветуёте книги по такого рода алгоритмам.
4) Приведите примеры готовых приложений, решающих схожые проблемы с закомментированным исходным кодом и описанием алгоритмов
Понимаю, мысли изложил несвязно, но у меня уже каша в мозгах полная. Заранее спасибо.
Примечание:
Тут есть некоторый ряд преследуемых задач:
1) инклюд только требуемых файлов (по идее даст прирост производительности)
2) возможность выполнения инструкций (передача переменных между классами, использование методов классов и т.п.) для построения более гибкого приложения.
3) возможность изменения поведения системы без изменения большого количества кода (сделать определённые объекты как можно более независимыми в плане строгой привязки к методам друг - друга)
Пока что у меня получается что-то типа интерпритатора к интерпритируемому языку =(
Ильдару: нужен алгоритм для построения и удовлетворения зависемостей между отдельными объектами наиболее эффективным путём. Я склоняюсь к использованию графов, но хочется узнать альтернативы. Также есть ряд технических вопросов.
To crimaniak: по идее __autoload() работает быстрее ручного инклюдинга только на серверах с php акселераторами. Да и при большом количестве файлов autuload кушает много больше ресурсов.
Примечание:
To epsiloncool:
1) Тема очень интересная,осознаю
2) Гм, ini файлы должны использоваться только для загрузки, грубо говоря, скелета приложения, а также для построения относительно простых связей между некоторыми объектами на основе методов этих классов. Вроде его будет достаточно. Использование массивов будет более кушающим (тоже самое считывание файла + unserialize)
3) Эмм...тут возможно, я вас не совсем понимаю. Действительно, по замыслу, большая часть объектов будут обращаться к экземплярам классов библиотек через массив ввида $sload->arrayofobj['classname'], но для связи между объектами конкретных приложений я хочу отказаться от такой структуры с помощью адресации инструкций непосредственно sload
Примечание:
По пункту три: sload имеет методы для исполнения методов загруженных классов, заданию переменных и их передаче по некоторым введённым лексемам
Примечание:
Чувствую себя изобретателем велосипеда...
Дошёл до того, что пишу интерпритатор для методов загруженных классов с поддержкой джамповых переходов...
И это на php
Примечание:
Упсс, насчёт сериализации погорячился, просто мозги уже кипят =)
В принципе, формат не столь важен, так как по ини файлу грузиться только строчек 7-8, где определяется, каким образом будет грузиться основной сценарий, идея в том,чтобы на простейшем псевдоязыке указать основные логиеческие связи между объектами, на данный момент мне кажется рациональным решением.
Уже научил проверке на эквивалетность с последующим переходом в нужный блок, использованию методов объектов, назначению переменных и выходу из блока кода и из всего псевдо макроса в целом.
Об адрессах: что-то вроде того, кстати, не подумал об одномерности, огромное спасибо, а то понял бы уже, когда бы всё написал, подумаю, как лучше сделать. Да, для перехода к объектам, созданными другими объектами просто смотрятся ключи подмассива массива sload->arrayofobj[$objname]
eval(), конечно, хорошая вешь, но есть два минуса: сорит переменными и надо строго следить за форматированием, также, всё-таки, я как раз хочу урезать функциональность, ибо я намеренно хочу исключить возможность создания переменных кроме одной (массив для внутренних нужд, определяется как private в sload, любая новая переменная - именованная переменная в этом массиве) или объявление\использование сторонних классов\функций
про аутолоад: =) я почти уверен, что, как обычно, накосячу
А вот про зависимости: я толком даже и не представляю, какие зависимости будут =( Мне надонаписать что-либо как можно более абстрактное
Примечание:
to tankha:
собственно, я тогда, когда работал с этим, отошёл от привязки к определённым средствам, просто решил ограничиться интерфейсом и написал объект по ini, в качестве примера, следующий этому интерфейсу. Заказчика тогда это удовлетворило. К сожалению, финансирование продолжалось пару месяцев, и кроме набора сырых классов под фреймворк у меня ничего не осталось =(
Да, вы всё-таки некропостер)