[wp-hackers] Plugin API: Unique ID explanation

[Jacob Santos]

The discussion on PHP4 is only that the developer has to be extra careful that they include the reference to $this and not just $this, because while it may work on PHP5, it isn't going to on PHP4, so the unique ID is never going to be assigned. I do not want this to be a PHP5 vs PHP4 discussion as it is outside the scope.

I'll toss number 1 aside as it is irrelevant. I usually "namespace" my functions with dragonu_whatever(), plugin_name_whatever(). I do see many plugin developers use this logic. I can see how the "GSD" paradigm fits in with development. You aren't being paid, nor will you receive any payment. If doing it "correctly" adds another 3 hours or so to development, I can see where doing it poorly makes a bit of sense [1].

For number 2, I see many plugins which include all of the plugin code in one single class. I could not extend their class without being a clone of that class. The problem is reuse and the pattern which does not include creating multiple instances of a class should not be not be using array(&$this, 'method');. I will still say that the design would be better off not needing to use array(&$this, 'method').


I'm getting away from my original point, which is that the past code does the best job at attempting to set up an unique ID. The problem is that the language itself does not provide a very good way at doing it reliably, so while you would be correct, the limitations of the language means that it is a design flaw of the plugin developer to not consider that perhaps it would not be a good idea to do it in that way.


Jacob Santos

[1] I've been told and read elsewhere that when doing freelance work, the client doesn't give a flip about whether it is done correctly, they just want it done and as soon as possible. I do not yet subscribe to the GSD paradigm as while I have done it in the past, I've found that having to rewrite code completely or not being able to reuse previous code was worse and more time consuming than attempting to do it right the first time.



On Fri, 07 Aug 2009 17:53:33 -0500
Chris Jean <gaarai at gaarai.com> wrote:

> Then what you are discussing does directly interest me as I use the
> "array(&$this, 'method')" construct often in basically all of my code. I
> have my reasons:
> 
>    1. Bundling all the code into a class allows me to freely code
>       without worrying about variable or function name collisions.
>    2. I make use of OOP features such as inheritance that allows for
>       rapid code production.
>    3. Code that I write ships to people who don't give a flip about PHP
>       4 or PHP 5. If my code fails because it's PHP 5-only, they don't
>       blame their host, they blame me.
>    4. In some of my more advanced projects, I have multiple instances of
>       individual classes that communicate using actions and filters.
> 
> Getting back to the topic. You're saying that the way I code is a design
> flaw. At no point did any documentation say or even hint that even
> though latching actions and filters to objects worked, it really
> shouldn't be used.
> 
> Seems to me that the design flaw is in the add/remove functions. By no
> means am I criticizing those who built or worked on it, but if you are
> going to claim design flaw, point the finger toward the actual design
> that has the flaw rather than the code the exposes the flaw.
> 
> I understand how everything works just fine when using a standard
> function or static method, but frankly, that type of solution will not
> work for some of my code. Much of my code needs to be instantiated, it's
> how things function. Furthermore, some of my code instantiates multiple
> instances of a class, each of which needs to have its own unique
> action/filter references.
> 
> When you mention the overhead, are you saying that the action/filter
> calls themselves have overhead or are you saying that using &$this
> methods have increased overhead?
> 
> The main thing I'd like to know Jacob, is what you are looking for. You
> brought up the topic as some sort of call to action. What kind of action
> are wanting?
> 
> Chris Jean
> http://gaarai.com/
> http://wp-roadmap.com/
> http://dnsyogi.com/
> 
> 
> 
> Jacob Santos wrote:
> > http://core.trac.wordpress.org/ticket/10535 is the correct link, I
> > apologize for the confusion. The point is that people are using:
> >
> > add_action('whatever', array(&$this, 'method'));
> >
> > and people are attempting to make it to where if you do,
> >
> > remove_action('whatever', array(&$this, 'method'));
> >
> > that it will in fact remove the method from 'whatever'.
> >
> > Currently, there are many use cases where it still does not. An
> > attempt was made in October of 2007 to make it to where it does,
> > however, the algorithm was flawed and only worked with a few use
> > cases. The attempt is being made now, to extend the use cases that it
> > works.
> >
> > My contention was that instead of working around design flaws used by
> > plugin developers that plugin developers should understand that
> > functions and static methods do not suffer from the above. Every use
> > case will work correctly. Furthermore, the hope to get the code to
> > work on PHP4 is a fantasy, a farce.
> >
> > It is a fun problem with an interesting solution, which is what peaked
> > my curiosity. However, these two examples are far better as they don't
> > suffer from WTF?s.
> >
> > add_action('whatever', 'some_function');
> >
> > add_action('whatever', array( 'some_class', 'some_function' ));
> >
> > These two examples work with both PHP4 and PHP5.
> >
> > I'll explain further that as many times as the function is used, it is
> > a really bad idea to use the the first example as the overhead is
> > quite a bit (overall it is small, but when you start to use it around
> > 3000 to 4000 times, the total time just from that function starts to
> > exceed 1 second (which is really, really just terrible). Good news is
> > that most people will never get around that amount (or so we hope).
> >
> > Jacob Santos
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers


-- 
Jacob Santos <wordpress at santosj.name>