Re: Template style question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <robert@xxxxxxxxxxxxx> 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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux