[wp-hackers] Discussion About BackPress

[Michael D Adams]

On May 10, 2008, at 7:52 PM, Jacob Santos wrote:

> It appears this discussion is hot on the bbPress forums, and  
> mailing lists. I do not subscribe to the bbPress forums/mailing  
> list and would rather not be part of that community at this time. I  
> was wondering if anyone has heard anything about it, the history  
> behind it, and where the future is going.

History:

WordPress and bbPress share a good deal of code and it's a huge pain  
keeping everything in sync.  The original idea was to have code that  
both apps drew from (ideally as an svn external to eliminate sync  
issues).

That lead to the idea that perhaps BackPress could be a sort of  
backbone on top of which people could write real applications.  You'd  
get a DB class, user/authentication system, convenience functions,  
sanitation functions, or any subset thereof.  All would be compatible  
with how WordPress works making for better integration/portability  
with other apps in the "family".

Most of the code was lifted straight from WordPress or bbPress.  That  
is to say, most of the code was put into BackPress in such a way as  
to make it easy for bbPress/WordPress to use BackPress.  To date,  
there has not been as much focus on how to make BackPress itself a  
solid piece of code or on how to make BackPress useable by other  
(future or current) real world apps.


Future:

bbPress trunk is running off of BackPress right now, though I don't  
know when the first based-on-BackPress bbPress release will be.   
WordPress just got it's first taste of BackPress in the tweaked  
WP_Scripts and new WP_Styles code.

As one of the main contributors to bbPress, I'd like to see WordPress  
use more of BackPress, not because I think it's good/bad/better/worse  
code, but because it will make my life easier.  That's not the best  
reason to switch WordPress to BackPress, especially if people think  
the code is terrible.  If we did make the switch, though, there'd be  
a lot more attention and eyes or BackPress to make it better.

It will take a significant but not unrealistic amount of work to get  
WordPress using BackPress.  Having two apps using BackPress would  
also show us better where integration issues arise.

To have any substantial future, BackPress needs a thorough beating by  
people like yourself. Additionally, it's never been used to build a  
new app, only to consolidate code between two existing apps, so it's  
hard to say if it worth its salt in its current state or what, if  
anything (and I'm sure there are many anythings), needs to change in  
order to get it to a useful state.

Right now, it's "these are some sacks full of functions".  The only  
advantage BackPress' current classes give over WordPress' current  
code is better portability between apps (and the ability to do some  
small extensions on top of them).  Most of the classes are meant to  
be instantiated once ever; really they're there for "namespacing"  
purposes.

In the end, I don't much care if the code is pretty or ugly or  
whatever, as long as it's useful.  I'm not by any means making the  
claim that it's currently useful :).  I can say that it functions  
(though again note the limited scope in which it's been used so far).

> The repository. Well, it is difficult to talk about a product that  
> is in the early works. I know from my past projects that most of  
> the work didn't come together until towards the end, so I can  
> understand that saying, "It sucks!" does nothing to further the  
> thought process going on with BackPress, (it does remind me of a  
> project I've seen on the IRC chat and that project was equally  
> terrible).
>
> Food for Thought:
>
> Objects Design is not so simple as throwing a bunch of functions  
> together into an object and calling them methods.
>
> Class Patterns are there for a reason, to get past the limitations  
> of language design to improve the work flow of the component's design.
>
> The desire to keep an object small is logical from the fact that  
> once the object is initiated, the methods, and data must be stored  
> in memory during the duration that the object is in use. (This  
> might not be true of PHP, but it is of at least other languages, so  
> one could assume.)
>
> One problem I've seen with other applications in their usage of  
> objects is that they either separate everything and build off  
> dependency off dependency, creating something that goes so deep it  
> is almost impossible to comprehend the work flow and impossible to  
> easily change anything without complete redesign/restructure.
>
> The second problem is that once a bad design is locked in, it is  
> then impossible to change because of backwards compatibility issues  
> happen.
>
> I'm no expert with object software design, but over the years of  
> making more than my fair share of mistakes, I've learned a thing or  
> two.

As does BackPress, your critiques suffer from over abstraction.  Can  
you point to specific examples that give you the "It sucks!" reaction?

BackPress no doubt suffers from over abstraction, under abstraction,  
just plain bad abstraction, and any other name for "bad code" you can  
come up with.  It also suffers from a major lack of documentation  
(though, as you note, it's early).

I'd really value your input and, in particular, any contributions you  
want to make.  We can start a new mailing list for discussion, if  
that'd make things easier.  I also just realized that the trac  
instance for BackPress requires authentication for anyone to even  
view it.  Lame.  I'll open that up so things are more transparent.

Mike