Re: OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...

Robert Cummings wrote:

On Thu, 2006-06-01 at 15:01, John Meyer wrote:

John Nichel wrote:

Do what I do, and don't do OO. ;)

there an 'oo baby' joke in there somewhere :-)

In other words, do what works, realizing that 99 percent of the time that you're doing indivdual sites, and ignore dogma? Hmm, what a concept!

hmm I didn't grok that comment.

Other than basic inheritance and the namespace features provided by classes, I don't see much else that is critically useful. There's was a strange push for all kinds of advanced OO features in PHP5 and somehow that got some kind of ball rolling to make things more and more complicated. Other than the pass objects by reference by default feature of PHP5 and better constructor/destructor support... the rest is just tooth decaying candy... and Jochem seems to be getting cavities it seems -- time to floss and brush the crud away ;)

like you Rob I have a big OO codebase, only mine is php5 only and not in a state were I'm comfortable publishing it (one needs to know too much about the codebase concepts and firebird DB to make it relevant without documentation that I will probably never have time to write :-/) none the less is stable, robust, powerful and flexible - it cost me about 2 years of near fulltime development and I run a number of well paid projects on it - brushing it away is not an option at this stage in the life of the code, not that I consider it cruddy enough either. at every BC breaking turn in the php5 road (since beta3) I have managed to refactor my codebase without actually changing too much or having break the functionality the codebase offer[s|ed] - such refactoring does cost time though in terms of having to think carefully about how to proceed and the testing involved in making sure things still work as intended ...

One of my biggest peeves about stuff changed that worked but wasn't necessarily purist... not letting values be passed to functions expecting a reference parameter. I mean really, PHP knows it's a literal, so why can't it just make it safe. Ugh. Nope, now we gotta add an extra line of userspace code to first assign the value to a variable to do exactly what PHP could so much faster do for us. Similarly functions returning references. Used to be you could return a null or false value on encountering a problem... but noooooo, now you have to spank youself and write $retValue = null; return $retValue. *pfffft*.

now I understand the annoyance Rob refers to but I can live that that one because I have read enough to understand that there is a segfault issue and although in theory it should be the engine that just 'deals' with it it can't without a lot of developer headache and/or BC breakage and/or performance issues playing up - so its the lesser of 2 evils. besides I often end up doing something like (a few more chars but no extra lines ;-): return ($r = false); my gripe is about the abomination that is 'strictness for the sake of it' which is most evident in the OO code - and not only is it strictness per se but the continual movement of the goals posts (and incremental increase) regarding the rigidity of what is allowed (read 'what is correct') - it's not like some very strict OO stuff was introduced in the beginning, no, in the beginning [of php5] things were more relaxed and even now after 2 years php5 is still treated as a beta product with regard to the way functionality is changed according to the whim of whoever has commit rights (or there abouts). and I understand Johns sentiment about not using OO - but there are complex things you can structure and design (from my personal point of view) which cannot so easily/ transparently be done with purely procedural code. that said I have plenty of reusable function library and pure procedural sites running - I use both depending on suitability. generally I like thinking in OO terms - and it often matches with stuff I do in javascript on the client side in terms of working with objects (yes I know javascript is prototypal iso class-based but that is not the point :-) not that procedural code is completely safe from the purists that are out 'to protect the developer' - remember how flexible array_merge() used to be??? well try stuffing anything other than an array into it these days and you get a big fat E_WARNING. and I am pretty damn sure *that* had nothing to do with fixing a segfault.

BTW, I still love PHP :)

heh me too :-)

Cheers, Rob.