On Tue, November 8, 2005 6:23 pm, Robert Cummings wrote: > On Tue, 2005-11-08 at 19:04, Richard Lynch wrote: >> On Sat, November 5, 2005 5:03 pm, Leonard Burton wrote: >> > On 11/5/05, Robert Cummings <[EMAIL PROTECTED]> wrote: >> >> On Sat, 2005-11-05 at 14:55, James Benson wrote: >> >> > Give smarty a try rather than re-inventing the wheel >> >> > >> >> > http://smarty.php.net >> > >> > Reinventing the wheel is much better than either the LGPL or GPL. >> > Writing GPL or LGPL code on PHP is just wrong. Either keep the >> code >> > for your own use or use the PHP license. Most of the stuff I see >> that >> > is distributed under the [L]*GPL isn't worth much. If PHP can be >> > written under the PHP license why can't small little apps that is >> > written in PHP? I release my code snippets (from time to time) >> under >> > either the PHP or BSD license. >> >> Ooooh, if I fan the flames a little, can we turn this into another >> flame war for BOTH CMSes *and* licensing?! Pretty please??? >> >> And let's work in the Nazis somehow, okay? >> >> [that was sarcasm, folks] >> >> Every template engine I've used, I felt like I was being forced to >> write code while my hands and arms were wrapped in Taffy. >> >> I don't see any need for another one to be built, but I never saw a >> need for the first one either, so there ya go. > > I don;t think your the target audience, you don't see the need for OOP > either :/
au contraire! I see [have seen] many needs for OOP. The largest group of those needs is nowhere near a web-server. I spent most of a decade writing Lisp code for AI research. You can't get much more OOP than Common Lisp. Makes PHP's OOP look wimpy. :-) :-) :-) I also see a HUGE need for OOP in large-scale coding projects in PHP with multiple developers, particularly with one (or very very very few) Software Design Architects, and a whole bunch of less-experienced programmers. What I abhor is the current practice of conveting the simplest stupidest one-man or small-team site into this monstrous OOP mess, usually by somebody who actually knows NOTHING about OOP when you get right down to it. He copied his coding style from another script who doesn't really "get" OOP, who copied HIS coding style... and so on. Here's how I know that OOP is probably not the right solution: 1. None, or very few, classes actually inherit from anything. At that point, OOP is most likely being abused as a namespace solution. Which is "fine" in PHP, as there is no other reasonable alternative. Unfortunately, instead of coding it like a namespace solution, it's this weird set of coding practices that would, in theory, be "good" in OOP, if there were share behaviours and properties among the classes... Which there aren't since there is no inheritence. 2. Too many class, all the same This is best explained by example: I cannot count the number of times I've seen somebody decide to have a single class for each and every table in their DB. If you think this is a Good Idea, please spare me the long explanation of "Why" it's a Good Idea. I heard it. It makes no sense if you analyze it deeply-enough and understand what all the concepts of OOP actually mean. 3. Performance suckage OOP has overhead, by definition. A *really* good Software Design Architect, with no less-experienced developers to worry about, 99.9999% of the time, could write a more efficient non-OOP equivalent solution for any OOP solution. And they'd write it faster, with less code, and it would better fufill all the promises of OOP in the first place. This is all a HUGE *if* because large software packages are seldom written, in whole, by a single Software Design Architect. The point being this: There is a price you pay for the benefits of OOP. Performance. This is an acceptable price when the benefits (and they are legion) are real and achievable. Unfortunately, for 99% of the scripters out there, pounding out OOP "scripts" in PHP, they benefits are not real, and not even achievable, for the resources/needs they have. Sometimes the OOP systems I see are *so* over-engineered, the performance loss is significant. For anybody still reading this missive. Please, just stop and think about the classes you are creating. Do they inherit any behaviour? If not, can you re-write them in better code as procedural while maintaining good solid modularity? Because you really don't gain the much-vaunted "code-reuse" of OOP just by copy and pasting the class from here to there. You can do that with functions or .inc files for Pete's sake. If you find two classes that are very similar, and you abstract out a common super-class, THAT is OOP code re-use at work. Re-using a class on another project is a chimera of code re-use. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
