Re: PHP object oriented problems

Hi,


> At 07:35 PM 7/27/2001 +0530, Srinivasan Ramakrishnan wrote:
> >Read the PHP manual. I find the manual quite sufficient for all my needs.
If
> >you meant that you were new to object oriented programming, then
> >
> >a) Start learning Java or C++ (would recommend Java for learning OOP)
> >or
> >b) Don't use OOP in PHP, most PHP programmers don't use them, not
frequently
> >anyway. OOP is not idiomatic in PHP.
>
> I would respectfully disagree.  You don't need to learn another language
to
> learn OOP

Agreed, although I'd say that learning OOP on a language that does not
completely support it is double the effort. YMMV, but I knew C++, as well as
a good bit of object based programming using JS before I knew Java. But I
felt it idiomatic only when I used Java. In C++ your concentration on
learning the concepts of OOP is distracted by the need to keep track of
pointers to objects, pointers to strings etc., that you never really get
around to thinking in objects, being bothered all the time with the low
level issues. Now when I program in C++ I find thinking in objects much
easier, and produce cleaner designs. As I said, YMMV.

> nor should you NOT use OOP in PHP.  Of my last five PHP projects, four
used
> OOP.

I repeat PHP does not use OOP idiomatically. Infact using OOP slows down
PHP. No, this is not me talking through my hat, Rasmus Lerdorf admits to it
on an interview. I forget the exact one. Anyway, there are a lot of
unresolved questions about OOP in PHP. Like for example what about multiple
inheritance? Documentation didn't exist for things like this the last time I
saw. The scope resolution operator, :: has been introduced only in version
4. That is to say, the language as a whole is still coming to terms with
OOP.

I'm not in anyway against PHP, infact my favorite hobby is to evangelise
PHP. But don't use a pickaxe to open the lock when you have the key.

> (the first one didn't because there was only me, and I didn't know
> enough).  OOP provides
> a wonderful structure both for thinking through the architecture as well
as
> clearer code
> for when multiple people are working on the project.  It's also easier to
> test your stuff as
> units without breaking other people's code.

Agrred again. The point here is that if these things are important enough
for you to take a performance hit, go ahead. That's why it's there in the
first place.


>
> I'd recommend buying some books.  MySQL/PHP Database Applications by Jay
> Greenspan
> and Brad Bulger is PHP specific.  If you're interested in objects, The Art
> of Objects by Lau

Have no experience with any of these, but

> or Building Web Applications with UML by Conallen

This I've read, and I'll just say this: This book is heavily ASP based (not
impossible to follow), and you need to know UML, ie you are required to be
familiar with OOP.

>are both well written,
> and not so obtuse
> like a lot of the OOP books out there.
>

Agreed, many OOP books only serve to confuse.

> But the best way to learn is write code, write code, and then write some
> more code :-)
>

I couldn't agree with you more.

The point I'm making is :
a) If you are new to PHP as well as OOP, don't try and learn OOP here if you
can avoid it. And even if you do, don't apply your OOP knowledge in
production code for atleast 6 months. It usually takes that much time even
for the brightest to get familiar enough with OOP to design object oriented
architectures that are truly useful and not broken in some way.

b) If learning a new language is too much pain, or you feel it is
unnecessary, still invest time in learning UML.

HTH,
Cheers,
-Srini
--
http://symonds.net/~sriniram

HWG: hwg-languages mailing list archives, maintained by Webmasters @ IWA