On Thu, 2006-06-01 at 17:43, Jochem Maas wrote: > 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. *hehehe* Sorry, the crud wasn't referring to your code, but rather to the "extras" that are causing you grief. There are critical aspects of any OO language that are absolutely necessary in OOD, but then there are also sugary parts that are just "nice to have" :) IMHO, it's wise to wait until new features completely stabilize before jumping on them. For instance my framework for all intents and purposes requires replacement services to adhere to a specific set of methods when overriding the default server object... in this way an interface is virtual, and never explicit. Some thing I find amusing in retrospect, is that when PHP4 came out I couldn't migrate to it fast enough, PHP3 just couldn't cut it in comparison to PHP4. But looking at PHP5 I feel (and I think others feel similarly) that I can easily wait till PHP6 comes out. Recently I've been rewarded with my patience... PHP5 now accepts the var statement again to declare class properties without generating a warning... if I had gone and updated my code to use public/private I'd have wasted my time :) > 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. Well there "was" a segfault, but that's fixed now, now the warning is thrown because of some purist attitude that says it's incorrect to pass a literal to a reference expecting parameter... I can see how that's an issue in C with pointers, or in a strongly type language like Java, but part of PHP's popularity is that while it shares a lot of functions with C, it is neither C nor Java, but rather a much simpler system that generally for all the novices out there "works well". > 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 :-) Ahh yes, I do like the elegance of prototypes too. They're a different kind of beast, but a very flexible one. > 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. *hehehe* Yeah. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
