[wp-hackers] Discussion About BackPress
emmensetech at gmail.com
Fri May 23 22:30:48 GMT 2008
Just curious - would love to beat on backpress. Is there even a development
branch of backpress that can be downloaded? SVN?
On Fri, May 23, 2008 at 6:21 PM, Michael D Adams <mikea at turbonet.com> wrote:
> 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
> 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.
> 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
> 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.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers