On 31 May 2005, at 15:21, Jochem Maas wrote:
seems like alot of spreadout functionality to be putting it in a
single
class (maybe I'm not seeing your example in the proper light).
That's possible, and I would only be able to implement a single
plugin class within any given file (assuming simplistic namespacing).
However, I do think that it's quite likely that any single plugin
will likely only implement one or two interfaces so it should not get
too messy. Think about photoshop here - you can just chuck plugins in
the plugins folder, and they are all handled in the same way,
regardless of whether they add file importing, exporting or image
processing functions, or even all three at once.
it sounds like lots of work, with the possibility that it will become
overengineered... which has the affect of:
1. making code slow (introspection and reflection are not the
speediest parts of the engine!)
2. make seemingly simple things difficult because of all the hoops you
have created for yourself.
Built-ins are almost always faster than 'userland' PHP code, and it
seems that this approach might hit quite a few sweet spots in that
respect. There's no particular reason this should have any great
impact on speed as it's not really any different to loading a bunch
of classes (something which is massively improved with an accelerator
anyway).
The plugin system needs to do several things:
* locate plugin files (just normal readdir calls)
* within located plugins, locate implementations of particular
functionality (a simple call to class_implements)
* run preferred implementation
Smarty has quite a neat plugin mechanism, but it's quite limited in
what it tries o do - for example there's no way you can directly
build block, modifier and function plugins with identical
functionality in a single file (though you could do it using a shared
class and a bunch of includes - exactly the complexity I'm trying to
avoid).
How might I achieve this without using these built-in functions, and
why might it be faster and less complex?
There are some very complex plugin systems, such as the one recently
added to MaxMediaManager which uses this model:
http://www.martinfowler.com/articles/injection.html#UsingAServiceLocator
but I'm wanting to keep things simpler.
but then there is nothing to suggest that you can't make it work
- the kind of thing you suggest doing is a good way of utilizing
the advantages of the object model.
I doubt it will be easy to write it well... but hey thats half the
fun right?! :-)
by all means hit the list with all your tricky little php5 problems,
I for one will be on the look out for them :-)
I get the feeling that it will actually be quite simple to write -
that's partly why I'm wondering what's wrong with it ;^)
1. what is the objective you wish to accomplish with such a 'system'?
The system I'm working on implements large chunks of functionality
internally. I want to make it switchable so that I can reconfigure it
to use external resources on a dynamic basis. My main aim is to build
a kind of host environment and reimplement my internal functions as
plugins so that all implementations of the functionality can share
the same interfaces. Many applications are built this way - Apache
and Dreamweaver MX spring to mind.
2. do you have a very strict definition of 'plugin'? (I have always
found the
word rather woolly/inexact)
That's part of the point. With the mechanism I'm thinking of, I don't
have to be too precise about what exactly a plugin might do - I only
need to define the different plugin interfaces (which can be very
strict) that it might conform to - implementation is wide open.
I'd welcome a discussion of plugin mechanisms generally...
Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in the picture
marcus@xxxxxxxxxxxxxxxxxx | http://www.synchromedia.co.uk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
