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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
