Плагины. События. Конфилкт имён функций.

[Чёрный]

Плагины. События. Конфилкт имён функций.

Здравствуйте!

Существует следующая проблема. Делаю портал, поддерживающий плагины. Не буду подробно описывать механизм. Важно лишь вот что: такие важные события как: удаление и добавление пользователей, изменение их прав, перемещение их между группами, - иногда должны обрабатываться некоторыми плагинами. Это я осуществил следующим образом. В папке каждого плагина, который может обрабатывать события, лежит файл event.php. При возникновении важного события диспетчер событий просматривает папки плагинов и последовательно включает (include) файлы event.php из каждого плагина. Всё бы ничего, да только плагин может быть довольно-таки сложной системой. И при обработке событий ему ну очень надо включить какой-то из своих файлов, чтобы воспользоваться внутриплагинскими функциями. Тут и возникает проблема: в файлах, включаемых разными event.php могут быть объявлены функции с одинаковыми именами. Тогда PHP начинает ругаться. Причём плагины могут писать разные люди, которые не договариваются друг с другом об именах функций. Кроме того, портал пишется для сервака, где админ не хочет/не может установить PHP5.

Есть ли у уважаемого ALL какие-нибудь соображения на сей счёт. Может быть в PHP существует недокументированная возможность как-нибудь unset функции? Или кто-то предложит совершенно иной подход? Только прошу, не предлагайте вовсе не реализовывать событий. Я уже пробовал - не катит.

 

[neko]

я непонял а как они вместе вообще будут эти плаги работать если там какие-то конфликты имен?

или "событие" это единственная ситуация когда ты будешь подключать файлы некскольких разных плагов?

если так, и если это происходит редко, то можно для каждого из них запускать отдельную версию php

 

[Demiurg]

> Кроме того, портал пишется для сервака, где админ не хочет/не может установить PHP5
а чем это могла бы помоч ?

в php4 вполне можно использовать классы как namespace исходя из них и разделять функции.

 

[neko]

если нет никаких договоренностей о именах, классы сами по себе ничем не помогут

 

[Demiurg]

уж об именах плагинов договориться можно.
А если никаких договоренностей нет, то .... и делать что-то бесполезно.

 

[neko]

ну а тогда придется договориться и о том, чтобы в плагах не создавали никаких глобальных переменных и/или фунций

впрочем тут есть один вариант принудительного оборачивания
я слышал это работает:
class A
{
inlcude 'A.php';
}

-~{}~ 18.03.05 22:25:

ан нет, неработает
дезинформация

 

[Чёрный]

neko, действительно, событие - не единственная ситуация, когда происходит подключения всех плагинов. Ещё такая же беда и с меню (блоками). Но с последними проблема решается так: вообще не использовать функций. А с событиями всё не так просто. Кстати, использование в плагинах глобальных имён не вызывает конфликтов в принципе.

Demiurg, существует масса договорённостей (хотя бы по поводу event.php), но вот на имена их нет. Более того, плагин может лежать в папке с любым названием, лишь бы она находилась в /modules. Потому разработчик плагина заранее не знает, как он обзывается сервером.

 

[[DAN]]

Однозначно использовать namespaces.
Причем бить в бубен тем, кто переопределяет в своем обработчике событий уже существующий namespace.
Ну а имена функций префексировать этим пространством имен.
Классы и остальные подходы будут бессмысленны и добавят лишних забот.

 

[Demiurg]

массы доковоренностей не надо. Надо просто разработчикам системы сесть и продумать интерфейс и выдвинуть некий список ограничений разработчикам плагинов. Так как твоей систему лучше тебя тут никто не знает, то эти самые ограничения лучше всего сформулируешь ты. Я в абстрактном понимании вижу одну проблему: доверять разработчикам плагинов или нет. У php давольно много возможностей проверки всяких там глобальных переменных и объявленых функций, но готов ди ты платиться за это производительностью ?

 

[Screjet]

[DAN]
namespacы вернулись? ..их же вроде выбросили еще до рождения релиза.

Чёрный
unset_func можно сделать. ПХП=опенсорц, Но местные адвокаты дъявола назовут это зарыванием головы в песок

Решения у тебя два:
1) реорганизовать всю свалку кода.
2) приступить к новой версии, уже предусмотрев все возможные нюансы.

 

[[DAN]]

Screjet, я не про встроенные ))
Просто самое оптимальное решение в этом случае - реализовать все модули (плагины) через namespacы.

 

[varan]

Все плагины писать на классах, имена которых должны начинаться с какого-нибудь сокращения от имени плагина pluginname_.
Т.о. надо будет договориться только об этих префиксах

 

[[DAN]]

varan, предыдущие высказывания читал?
Префиксы это aka namespacы и есть.
А вот аргументацию про классы хотелось бы услышать.

 

[Alive]

Автор оригинала: [DAN]
Префиксы это aka namespacы и есть.

Мне кажеться, что namespace'ы это не префиксы, а классы со статическим вызовом своих методов. А префиксы нужны, чтобы теперь эти классы имели уникальные имена.

Можно вообще обойтись простыми префиксами для ВСЕХ функций плагинов, например пусть все функции должны иметь вид function НазваниеПлагина_ИмяФункции () {}

 

[varan]

IMHO namespace'ы - это namespace'ы (как в c#, например), а не префиксы и не классы. Использовать функции плагинов как статические методы классов не правильно, т.к. им же и переменные надо где-то хранить. Да и неудобно это.
Кстати по-моему для сложной системы процедурно-ориентированное программирование не катит.

 

[Demiurg]

>Кстати по-моему для сложной системы процедурно-ориентированное программирование не катит.
а ты обоснуй.

 

[Нечто]

Я писал систему с плагинами и прочим барахлом процедурно с четкой иерархией и единым глобальным хешем всех данных.

Тема вообще бессмысленная. Человек отличается от животного выской способностью к экстраполяции, так почему же с самого начала не проектировать систему грамотно?!

 

[Demiurg]

>почему же с самого начала не проектировать систему грамотно?!
потому что система живет своими правилами, и изначально очень сложно прогнозировать во что она разовъется.

 

[Screjet]

Разве может пылесос развиться в атмосферный процессор?

Забываем про такое свойство: "масштабируемость". Так вот автор _изначально_ не предусмотрел это свойство. Причем не бывает оно бесконечно-резиновым.

зы. "каша из топора" (с) какой-то нар.

 

[Demiurg]

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