[wp-hackers] Re: [wp-trac] Re: [WordPress Trac] #3875: Proposal for a new plugin architecture

[jacobsantos at branson.com]

>> The magic method __toString(), which could be anything by the way you 
>> call it, would only print out what was in the __toString() only with 
>> echo or print, before 5.2.
>
> Enghh. I didn't know that. I'll look into it.
I forgot to mention, that with your code, nothing changes. You don't use 
__toString() magically, you call it as a regular method. It should work 
with any PHP 4 and PHP 5 version. If you tried to do something like

$fn_idx = $obj . '[]' . get_class($obj) . '[]' . $fn;

instead of what you did, then you would have possible problems with PHP 
versions < 5.2.

$fn_idx = (method_exists($obj,'__toString') ? $obj->__toString() :  
'') . '[]' . get_class($obj) . '[]' . $fn;

So, it is great. However, if the developer then suspected that they can 
use their class name in messages and such, it could cause issues, unless 
this was made clear. I would almost rather it be called something else.
>
>> For array('class_name', 'method_name') :
>>
>> $fn_idx would equal: '[][]method_name'
>
> Also Enghh. Apparently I didn't read the callback pseudotype 
> documentation closely, because I didn't realize you could pass a 
> string representing a class name to grab a static method. Alright, I 
> will look into these issues (and the others you brought up) later 
> tonight.
I didn't explain myself that well. The method doesn't have to be static, 
for PHP 4 and 5, it will just treat it as static, meaning no $this 
usage. I don't believe many developers will use this method, unless they 
are adding the hooks outside of their class (and even then, from the 
example they use the constructor, which wouldn't mean static). From what 
I've seen, most choose to add hooks from inside and using $this or if 
outside, with the constructor. So no static usage. However, it would be 
better to use defensive programming to keep from any possible future 
bugs from occurring.

It is a possible use case and I'm glad you are examining it.

The greater problem is the inability to remove classes. So the ability 
to remove classes should hold great priority than to be able to add two 
classes with the same names but with different values. The values can 
change at any point...

I suppose then that the solution would mean that you reference the 
object in the array when you are adding it. You would then have to 
iterate through the same class and method names and do a class 
comparsion on each one. Since you reference the class, when the 
properties of that class are changed, then (in theory) the properties in 
the $wp_filters array would change also. The serialization can not do 
that (or so I think).

It would be slower, but would provide a solution that wouldn't require 
any modification to any existing and further code. I will see about 
providing a patch and use cases.