[wp-hackers] Re: [wp-trac] Re: [WordPress Trac] #3875: Proposal
for a new plugin architecture
jacobsantos at branson.com
jacobsantos at branson.com
Tue Jul 31 19:04:40 GMT 2007
>> 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
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.
More information about the wp-hackers