

Handling Plugins in PHP - ircmaxell
http://blog.ircmaxell.com/2012/03/handling-plugins-in-php.html

======
jakejake
Excellent post. I like seeing advanced PHP stuff here. The ignored step-child
of languages around here, it seems.

Even though I'm a bit of an OO snob and use design patterns in my work, I also
like the simplicity of WordPress's plugin system. I'm not even sure what it
would be called but it's proven to be really effective with thousands of
plugins.

~~~
ircmaxell
@jakejake Wordpress uses a procedural version of the mediator pattern (just
like Drupal's hooks).

As I said in my post, just because an application doesn't use classes, doesn't
mean it's not OOP or borrowing OOP patterns (and Drupal is actually a pretty
good example of that).

~~~
jakejake
I suppose resembles the mediator. I just find it to be really simple even
though I don't write code in a procedural style, I appreciate different
techniques. I think what makes me an OO snob is that I want the interfaces to
be there so my IDE or the compiler/interpreter can tell me if I missed a
parameter or didn't return the right type.

------
Loic
After 10 years of coding in PHP both OSS and products, creating 2 frameworks
used in production on numerous websites, I still wonder. Why do you need to
stuff interfaces in the mix? Why such complex patterns for something so
simple?

What I do and it works very well, is that I register plugins, callbacks in the
application configuration:

    
    
         $cfg = ['plugins_for_foo' => ['callback_one', 'callback_two', 
                                      [$Obj, 'three']]];
    

Then in the code I get my configuration like this:

    
    
         $callbacks = Conf::get('plugins_for_foo', array());
    

And I can iterate over them and activate them. It is fast, flexible, you can
easily test the callbacks in your unit tests, etc. Note that this is the
standard approach to load components with Django.

~~~
ircmaxell
Well, that just executes code. That doesn't alter your application flow,
unless you do that during runtime at (for lack of a better word) cutpoints.
And if you do it there, it's basically Chain of Responsibility, without the
"chain can be cancelled" part.

Just because the pattern has a name, doesn't mean it can't be simple. In fact,
a lot of the patterns are implemented all over the place under different names
and with slight tweaks.

An important point is to understand the difference between the patterns, and
know how to identify them. You can call a cow a lion, but it'll still moo just
the same...

~~~
Loic
What I mean is that most of the time people tend to fire heavy duty classes or
libraries to implement these patterns when you can implement just what you
need with very little overhead using the built-in language constructs.

I use both Python and PHP extensively and I find interesting that Python
developers try to go to the minimum that work while PHP developers try to go
the nice conceptually "right" way. I wonder if this is because the PHP
developers kind of need to prove that they can do rigorous OO programming with
their language or something like that where the Python developers do not care
and just do it the simple intuitive way.

~~~
jakejake
I like using classes with PHP not because I have anything to prove, but
because I like having auto-complete for my properties and methods in Eclipse
and I like getting compiler errors if I mistype a method name.

I'm getting more used to using generic structures and anonymous functions as I
write more Javascript but it bugs me sometimes having to look at the source
code or API docs to remember what parameters are available for a method call.

I guess it's being lazy in a different way - I like to do more work upfront so
I can be lazier later!

