[wp-hackers] Coding Standards: Functions vs. Classes

[Ryan McCue]

Andrew Nacin wrote:
> Don't be surprised if WP_Post happens in 3.5 or 3.6.

\o/

Is there a ticket tracking this? I'm very much interested in such an effort.


> The bump to PHP 5.2 happened with WP 3.2. Even then, we were mainly focused
> on removing dead code, rather than focusing on introducing new magic bits.
> (Slow and steady wins the race.) Someone mentioned PHP 5.3 namespaces, and
> that makes me laugh. In two years, PHP 5.3 adoption (in terms of WordPress
> sites) has gone from 4% to 10%. Not holding my breath. [1]

I'd say it'll still grow, but I think 5.2 is going to be dominant for a 
lot longer than we'd like. 5.4 and later might change that, but I don't 
see that the newer features are going to be enough to entice upgrading.

(It's a pet hate of mine that hosts are so slow at upgrading, and I'm 
sure there's something we could do about that ala GoPHP5, but I've got 
no idea how to actually do that.)

>   - Encapsulation and forwards compatibility. We've never quite gotten to
> the point where we've found our feet in cement due to backwards
> compatibility concerns, but it is very nice to be able to finalize a class
> and wrap select pieces in private properties in methods.

I'm sure there are people who will misinterpret this, so: `private` 
properties should be used for implementation details only. Anything you 
can forsee a subclass using should be `protected` instead. People who 
don't understand this make it so much harder for users. (This is mainly 
a plugin issue, not really core.)


> That also does not mean we're going to use classes everywhere. There are
> plenty of situations where procedural code is going to be better. One good
> example is to allow for easier barriers to entry (like template tags and
> conditional tags). I like classes and objects, but I don't drink the
> Kool-Aid.

I have to agree. While I still think WP_Error is a horrible imitation of 
exceptions (and westi will fight me to the death on that one ;) ), it's 
not worth the effort to rewrite everything around it now, and will 
probably confuse everyone who is just getting adjusted to WP_Error.

> That said, static class variables (as suggested) aren't exactly any better.
> They're not. Don't let anyone who tells you otherwise stand uncorrected.
> The benefit is that they let you hide data. The cost is that you are then
> hiding data *from yourself*. Global state (a global variable, a static
> method, a static property, what have you) is not testable. [2,3,4,5,6] So
> there better be a really good benefit for using classes in this case.

+1 on global state (although worth noting that all your links are by 
Misko, so it's not a wide range of sources there).

I disagree that static class variables aren't better than globals, for 
two reasons: namespacing, and association. If I see the $post global, I 
have no idea where that comes from, and I have to trace it. On the other 
hand, something like WP_Query::$post makes it obvious that the stuff in 
WP_Query is responsible for handling it.

Again though, changing everything around just for the sake of it isn't 
going to be a good idea. If we can do that cleanly and we have a reason 
for it though, I'm heavily in favour of it.

-- 
Ryan McCue
<http://ryanmccue.info/>