OOP leads to lousy websites?

[Chung Leong]

There has been a number of threads in this newsgroup concerning OOP and PHP.
Usually people just debate on which language is more (or less) OOP than
others. The merit of OOP in the web-programming context is rarely addressed.
So let me pose this question: Are websites built based on OOP principles
inherently less stable than those built "procedurally?" By "less stable" I
mean stability for the same amount of programming effort.

I'm incline to think it's true. Take string-handling. To get the length of a
string procedurally, you do strlen($s), while in OOP you would do
$s->Length() where $s is an instance of a string class. Now, if $s is null,
in the first case the function just returns zero, whereas in the second case
your page fails catastrophically.

[Tom Thackrey]

On 18-Feb-2004, "Chung Leong" <ch***********@hotmail.com> wrote:

There has been a number of threads in this newsgroup concerning OOP and
PHP.
Usually people just debate on which language is more (or less) OOP than
others. The merit of OOP in the web-programming context is rarely
addressed.
So let me pose this question: Are websites built based on OOP principles
inherently less stable than those built "procedurally?" By "less stable" I
mean stability for the same amount of programming effort.

I'm incline to think it's true. Take string-handling. To get the length of
a
string procedurally, you do strlen($s), while in OOP you would do
$s->Length() where $s is an instance of a string class. Now, if $s is
null,
in the first case the function just returns zero, whereas in the second
case
your page fails catastrophically.

Actually, to take the length of a string in OOP you would use strlen(), to
get the length of a String object you would use $s->length() or whatever.

OOP is a way of thinking about problems. Programmers were using OO
principles long before the first OO language. (C++ started as a pre-compiler
for C.)

The quality of the product is directly related to the quality of the design
and implementation. The language choice and even the methodology are
secondary. I've seen extraordinary programs written in assembler, Fortran,
and COBOL as well as crap written in Java, C++ etc.

Worry more about design and less about what language.

--
Tom Thackrey
www.creative-light.com
tom (at) creative (dash) light (dot) com
do NOT send email to ja*********@willglen.net (it's reserved for spammers)

[CountScubula]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:WM********************@comcast.com...

There has been a number of threads in this newsgroup concerning OOP and PHP. Usually people just debate on which language is more (or less) OOP than
others. The merit of OOP in the web-programming context is rarely addressed. So let me pose this question: Are websites built based on OOP principles
inherently less stable than those built "procedurally?" By "less stable" I
mean stability for the same amount of programming effort.

I'm incline to think it's true. Take string-handling. To get the length of a string procedurally, you do strlen($s), while in OOP you would do
$s->Length() where $s is an instance of a string class. Now, if $s is null, in the first case the function just returns zero, whereas in the second case your page fails catastrophically.

Personaly, and this is just me, and I not trying to convince anyone.

I feel oop programming in web scripting, should not be done, unless needed,
ie,redistributing, collabtitave works, etc..

scripting to me, is a bare stripped down enviroment, and the overhead due to
OOP, does not belong there.

IE:

$len = strlen($myString)

is same as defining an object, and in that object calling the same function
strlen to get the length of the string, too much overhead, again, just my
opinion.

I like OOP programming when I do certain compiled languages, but there when
I create an object, it is used for the life of the application, where as
scripting, it is read, built/interpeted/complied, then ran, then killed. and
this happens over and over for every web request.

Now on simple little sites, fewer than 1000 visitors a day, who cares, but
when you have 10,000 visitors a day, and the over head of OOP leads to only
a .01 second over head, no big deal right? wrong, total that up and you get
100 seconds of delay with 10,000 users. (flammers hold on, I now there is
more involved, but i am simplfying it)

I rarely use OOP in scripting, becouse I like to keep scripts simple, top
down, small, and fast.

Now OOP in PHP can be very usefull for building say images, graphs, zips,
etc. makes it easier for one to distrubute thier piece of code.

Ok, I am done rambling,

--
Mike Bradley
http://www.gzentools.com -- free online php tools

[rush]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:WM********************@comcast.com...

There has been a number of threads in this newsgroup concerning OOP and PHP. Usually people just debate on which language is more (or less) OOP than
others. The merit of OOP in the web-programming context is rarely addressed. So let me pose this question: Are websites built based on OOP principles
inherently less stable than those built "procedurally?" By "less stable" I
mean stability for the same amount of programming effort.

I'm incline to think it's true. Take string-handling. To get the length of a string procedurally, you do strlen($s), while in OOP you would do
$s->Length() where $s is an instance of a string class. Now, if $s is null, in the first case the function just returns zero, whereas in the second case your page fails catastrophically.

I do not think website app programming is very different from any other kind
of programming, so if you find OO a good way to program in general, you
would also find it to be a good way to develop web apps. And other way
around, if have never felt comfortable with OO, you will also probably
incline to use procedural programming for web sites.

as for reliability, for me OO makes it easier to make code of better quality
and more robust. But that's just my experience. With OO, as with any other
programming approach you need to have a good measure for it and approach.
But if you use it just because you have to, you usually get very bad
results.

rush
--
http://www.templatetamer.com/

[Berislav Lopac]

Chung Leong wrote:

There has been a number of threads in this newsgroup concerning OOP
and PHP. Usually people just debate on which language is more (or
less) OOP than others. The merit of OOP in the web-programming
context is rarely addressed. So let me pose this question: Are
websites built based on OOP principles inherently less stable than
those built "procedurally?" By "less stable" I mean stability for the
same amount of programming effort.

I'm incline to think it's true. Take string-handling. To get the
length of a string procedurally, you do strlen($s), while in OOP you
would do $s->Length() where $s is an instance of a string class. Now,
if $s is null, in the first case the function just returns zero,
whereas in the second case your page fails catastrophically.

OOP is really (in any language, although some give you no alternatives) just
a way to organize your code, and nothing more.

When you think of it, the actual programming is done with only a very small
subset of actual commands in any (high-level) programming languages: not
much more than numerical operators, assignments, if-switches and for loops.
Everything else, from simple ++ and ternary operators, switch statements and
while and other loops, to functions and eventually to objects and methods,
is just tools that make programmer's job easier by helping him reuse the
code and reduce the number of possible problems.

In the end, it all comes down to how good you are in organizing your code.
In the example above, there is no reason why would $s->Length() make the
page fail catastrophically -- you can write it so that the Length() method
also returns a zero. Also, if the strlen is called from another custom which
fails to return zero when strlen returns one to it, the page can fail
catastrophically just the same.

Imagine that there is *no* functions in PHP. No strlen, no in_array,
nothing. Would we be able to program with it just as we do now? Of course,
except that all those useful functions that are precompiled into it will
have to be re-written from scratch using simple operators and if-statements.
In any language, its strength comes primarily in the scope of the code
library which comes with it, and this is especially true of PHP. And this is
true not only for functions, but also for objects, except that here the
library we get with the language is not nearly that extensive. Some
languages, like Java, provide you with a myriad of prepared classes and
objects and interfaces and methods which you can use in your program out of
the box; if they were not there, you would have to write them yourself.

And when you write your own library -- either procedural (functions) or OO
(objects, methods...) -- it is exclusively up to the programmer to cover all
possible incomes and returns to prevent the library from acting
unpredictably. You need to know what objects there might exist in your
application and what functions they might perform, just as you need to know
which chunk of procedural code could become a good function, or whether
there are several functions hiding one inside another.

Some people find it easier to think procedurally, and others find it more
productive to use object-oriented approach; it all comes down to the code
organization.

Berislav

--
If the Internet is a Marx Brothers movie, and Web, e-mail, and IRC are
Groucho, Chico, and Harpo, then Usenet is Zeppo.

[Andy Jeffries]

CountScubula wrote:

Personaly, and this is just me, and I not trying to convince anyone.

I feel oop programming in web scripting, should not be done, unless needed,
ie,redistributing, collabtitave works, etc..
Or large projects...
I like OOP programming when I do certain compiled languages, but there when
I create an object, it is used for the life of the application, where as
scripting, it is read, built/interpeted/complied, then ran, then killed. and
this happens over and over for every web request.
But it can be stored across page accessing in $_SESSION.
Now on simple little sites, fewer than 1000 visitors a day, who cares, but
when you have 10,000 visitors a day, and the over head of OOP leads to only
a .01 second over head, no big deal right? wrong, total that up and you get
100 seconds of delay with 10,000 users. (flammers hold on, I now there is
more involved, but i am simplfying it)
BUt that's 100 seconds of delay spread over 10,000 users or still .01
second over head per user. That's not a flame, it's just your point is
either wrong or incorrectly stated.
I rarely use OOP in scripting, becouse I like to keep scripts simple, top
down, small, and fast.
For small sites I agree. For large sites, they can be easier to
maintain using classes.
Now OOP in PHP can be very usefull for building say images, graphs, zips,
etc. makes it easier for one to distrubute thier piece of code.

Ok, I am done rambling,

And why, not it's good fun to have rambling conversations...

Cheers,
Andy

[CountScubula]

Perhaps I did mistate the whole 100 seconds via 10,000 visits/.01sec delay.

More of the effect if you tend to have a lot of hits at one time (generaly
if you have 10,000 visits in a day, that well over 50,000 hits).

So if you have many hits at same time, then the .01 delay becomes slightly
more becouse durring this time, cpu cycles is limited, and then spread
across more proccess, also, if you have lots of visits, your server might
delay a connection here or there becouse it reaches its max
threads/children, the faster a script can be built up / torn down, then the
more free the server will be.

Again, I ramble, it is 3:00am for me, and I have a plane to catch at 6:00am,
and If I go to sleep, there will be no chance of waking up.
--
Mike Bradley
http://www.gzentools.com -- free online php tools
"Andy Jeffries" <ne*****@seirffej.reverse.previous.word.co.uk> wrote in
message news:10****************@ersa.uk.clara.net...

CountScubula wrote:

Personaly, and this is just me, and I not trying to convince anyone.

I feel oop programming in web scripting, should not be done, unless needed, ie,redistributing, collabtitave works, etc..

Or large projects...

I like OOP programming when I do certain compiled languages, but there when I create an object, it is used for the life of the application, where as
scripting, it is read, built/interpeted/complied, then ran, then killed. and this happens over and over for every web request.

But it can be stored across page accessing in $_SESSION.

Now on simple little sites, fewer than 1000 visitors a day, who cares, but when you have 10,000 visitors a day, and the over head of OOP leads to only a .01 second over head, no big deal right? wrong, total that up and you get 100 seconds of delay with 10,000 users. (flammers hold on, I now there is more involved, but i am simplfying it)

BUt that's 100 seconds of delay spread over 10,000 users or still .01
second over head per user. That's not a flame, it's just your point is
either wrong or incorrectly stated.

I rarely use OOP in scripting, becouse I like to keep scripts simple, top down, small, and fast.

For small sites I agree. For large sites, they can be easier to
maintain using classes.

Now OOP in PHP can be very usefull for building say images, graphs, zips, etc. makes it easier for one to distrubute thier piece of code.

Ok, I am done rambling,

And why, not it's good fun to have rambling conversations...

Cheers,
Andy

[Tim Tyler]

Chung Leong <ch***********@hotmail.com> wrote or quoted:

Are websites built based on OOP principles inherently less stable than
those built "procedurally?" By "less stable" I mean stability for the
same amount of programming effort.

I'm incline to think it's true. Take string-handling. To get the length of a
string procedurally, you do strlen($s), while in OOP you would do
$s->Length() where $s is an instance of a string class. Now, if $s is null,
in the first case the function just returns zero, whereas in the second case
your page fails catastrophically.

....making it much easier to identify the presence of the problem and
to locate the source of it during testing - thus saving on debugging time.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[Andy Jeffries]

CountScubula wrote:

Perhaps I did mistate the whole 100 seconds via 10,000 visits/.01sec delay.

More of the effect if you tend to have a lot of hits at one time (generaly
if you have 10,000 visits in a day, that well over 50,000 hits).
I agree with what you are saying.
So if you have many hits at same time, then the .01 delay becomes slightly
more becouse durring this time, cpu cycles is limited, and then spread
across more proccess, also, if you have lots of visits, your server might
delay a connection here or there becouse it reaches its max
threads/children, the faster a script can be built up / torn down, then the
more free the server will be.
I'm working on a site that currently does 40,000-90,000 page impressions
per day and there are quite a few objects on the site and it responds
very quickly (even though it's hosted in the states and it links to
various Ad providers).

What I would say is : Objects obviously have their place in speed of
development/ease of maintenance for large sites. If your site is slow,
look at optimising it - but do it sensibly. Measure how long your
queries take, measure how long your slowest pages are and where it
spends most of the execution time.

I bet object construction/usage are no-where near the top of the
optimisation pile....
Again, I ramble, it is 3:00am for me, and I have a plane to catch at 6:00am,
and If I go to sleep, there will be no chance of waking up.

Hey man, I'll help you stay awake with this rambling conversation if it
helps....

Cheers,
Andy

[Andy Jeffries]

Chung Leong wrote:

So let me pose this question: Are websites built based on OOP principles
inherently less stable than those built "procedurally?" By "less stable" I
mean stability for the same amount of programming effort.
I'll shove in my 2p-worth. I think the answer is no and generally the
opposite is true. By following good OO design principles (objects do
one thing and do it well) you can build a more robust system as each
object is developed, tested then can be forgotten about.
I'm incline to think it's true. Take string-handling. To get the length of a
string procedurally, you do strlen($s), while in OOP you would do
$s->Length() where $s is an instance of a string class. Now, if $s is null,
in the first case the function just returns zero, whereas in the second case
your page fails catastrophically.

I'm not an OO purist, but I do think for relatively large sites OO can
help keep the system clean and easy to maintain.

I don't think you need a string object any more than you need an integer
object.

I think PHP achieves a mix of structured and OO programming with
unparalled excellence....

Cheers,
Andy

[Bruno Desthuilliers]

Andy Jeffries wrote:
(snip the rest, on which I globally agree !-)

I think PHP achieves a mix of structured and OO programming with
unparalled excellence....

<not-trolling>
Err... The lack of support for modularity (except when using OO) and
exception handling is IMHO not a sign of 'unparalled excellence'. I
think that this qualification would be better applied to Python (then
you could even add functional programming to the mix).
</not-trolling>

Just my 2 cents...
Bruno

[Andy Jeffries]

Bruno Desthuilliers wrote:

(snip the rest, on which I globally agree !-)

Jolly good... :-)

I think PHP achieves a mix of structured and OO programming with
unparalled excellence....

<not-trolling>
Err... The lack of support for modularity (except when using OO) and
exception handling is IMHO not a sign of 'unparalled excellence'. I
think that this qualification would be better applied to Python (then
you could even add functional programming to the mix).
</not-trolling>

<joking trolling>
Yeah, but I don't like the idea of programming in languages where
indentation affects how the program runs.
</joking trolling>

In all seriousness, I've tried looking at Python (most recently since
Nokia announced Python would be release for my 3650) but I just can't
seem to get on with it - it looks ugly :-)
Cheers,
Andy

[Chung Leong]

Uzytkownik "Berislav Lopac" <be************@dimedia.hr> napisal w wiadomosci
news:c1**********@ls219.htnet.hr...

Chung Leong wrote:
OOP is really (in any language, although some give you no alternatives) just a way to organize your code, and nothing more.

...

I see my original post didn't make clear what I have in mind. The issue in
question isn't OO programming in general, but OO in the specific context of
web-programming in real-world situations, where applications mainly performs
databases operations and generate HTML, and where projects must be completed
in a given time-frame. Let me thus refine my question:

Is the OOP approach more error-prone and does it requires more coding for
typical web-programming tasks?

Time here is the key. The more time it takes to implement a given set of
functionalities, the less time you have to polish the code and the less time
there is to test. Irregardless of programming technique, an untested
application is a buggy application. It doesn't help, of course, if a
particular technique is more error-prone than others.

The point of my example is that an OO approach requires additional coding to
keep a catastrophic failture from happening. Length() cannot simply return
0, as you said, because the method never gets called when $s is null. With
strlen(), at least the function gets a chance to handle the erroreous
condition in a reasonable manner.

[Tom Thackrey]

On 19-Feb-2004, "Chung Leong" <ch***********@hotmail.com> wrote:

Uzytkownik "Berislav Lopac" <be************@dimedia.hr> napisal w
wiadomosci
news:c1**********@ls219.htnet.hr...

Chung Leong wrote:
OOP is really (in any language, although some give you no alternatives)

just

a way to organize your code, and nothing more.

...

I see my original post didn't make clear what I have in mind. The issue in
question isn't OO programming in general, but OO in the specific context
of
web-programming in real-world situations, where applications mainly
performs
databases operations and generate HTML, and where projects must be
completed
in a given time-frame. Let me thus refine my question:

Is the OOP approach more error-prone and does it requires more coding for
typical web-programming tasks?

Time here is the key. The more time it takes to implement a given set of
functionalities, the less time you have to polish the code and the less
time
there is to test. Irregardless of programming technique, an untested
application is a buggy application. It doesn't help, of course, if a
particular technique is more error-prone than others.

The point of my example is that an OO approach requires additional coding
to
keep a catastrophic failture from happening. Length() cannot simply return
0, as you said, because the method never gets called when $s is null.
With
strlen(), at least the function gets a chance to handle the erroreous
condition in a reasonable manner.

Your example is too trivial. Plus the error you avoid is essentially using
an undeclared variable. I'd rather have it fail catastrophically than
subtly.

In general, OOP offers the opportunity to build tested, reusable 'modules'
which can be used to simplify DB access, HTML generation, etc. For anything
but the most trivial application, OOP should be an advantage.
--
Tom Thackrey
www.creative-light.com
tom (at) creative (dash) light (dot) com
do NOT send email to ja*********@willglen.net (it's reserved for spammers)

[Henk Verhoeven]

Chung Leong wrote:

(..)

I'm incline to think it's true. Take string-handling. To get the length of a
string procedurally, you do strlen($s), while in OOP you would do
$s->Length() where $s is an instance of a string class. Now, if $s is null,
in the first case the function just returns zero, whereas in the second case
your page fails catastrophically.

That depends on the exception handling. With try catch like in Java, C++
and php5, you can handle the the error and continue after the error
handler.

BTW, without implicit type conversion strlen(null) would have failed
too, or maybe caused a warning and returned null instead of null, which
without implicit type conversion will probably cause more problems later
on. I don't see why implicit type conversion would not be possible with
objects. In case of null->length() null could be converted to a String,
assuming the length method is only defined on String. But of course
defining length on the class of null would be more OOP ;-)

Henk Verhoeven.

[Chung Leong]

Uzytkownik "rush" <pi**@rush.avalon.hr> napisal w wiadomosci
news:c1**********@ls219.htnet.hr...

I do not think website app programming is very different from any other kind of programming, so if you find OO a good way to program in general, you
would also find it to be a good way to develop web apps. And other way
around, if have never felt comfortable with OO, you will also probably
incline to use procedural programming for web sites.
Good programming means finding the best approach for a given problem. I'm
perfectly comfortable with OO, have done plenty of programming in that
manner, and can't think of a different way of writing Windows programs. But
web-programming is very different from writing desktop applications. Scripts
usually finish execution in a blink of an eye. You're not sitting there
waiting for an event or a message. There're no windows or widgets to take
care of. And the scripting engine handles all the resource management.
Web-programming, it can said, is like writing glorified "hello world"
programs.
as for reliability, for me OO makes it easier to make code of better quality and more robust. But that's just my experience. With OO, as with any other
programming approach you need to have a good measure for it and approach.
But if you use it just because you have to, you usually get very bad
results.

OO makes it easier to make code look better than it actually is.
Encapsulation, more often than not, means stuffing sphaghetti into a
blackbox.

[Wÿrm]

<snip>

OO makes it easier to make code look better than it actually is.
Encapsulation, more often than not, means stuffing sphaghetti into a
blackbox.

If this is case, then problem lies much deeper in programming basics than in
just procedural or OO. Any program can be messy spaghetti, OO and
procedural, if person don't __know__ what they make and __why__.

[Phil Roberts]

With total disregard for any kind of safety measures "Chung Leong"
<ch***********@hotmail.com> leapt forth and uttered:

Is the OOP approach more error-prone and does it requires more
coding for typical web-programming tasks?

Nope. Because whenever I start a new site I just re-use the OO
components I developed for the last one. And if a bug gets fixed then
it gets fixed in every site.

If you do OO right first time it leads to LESS coding.

--
Phil Roberts | Dork Pretending To Be Hard | http://www.flatnet.net/

[Bruno Desthuilliers]

Andy Jeffries wrote:

Bruno Desthuilliers wrote:

(snip the rest, on which I globally agree !-) Jolly good... :-)

I think PHP achieves a mix of structured and OO programming with
unparalled excellence....

<not-trolling>
Err... The lack of support for modularity (except when using OO) and
exception handling is IMHO not a sign of 'unparalled excellence'. I
think that this qualification would be better applied to Python (then
you could even add functional programming to the mix).
</not-trolling>

<joking trolling>
Yeah, but I don't like the idea of programming in languages where
indentation affects how the program runs.
</joking trolling>

Don't you indent your code anyway ? Seriously, I *never* had a problem
with this in four years.
In all seriousness, I've tried looking at Python (most recently since
Nokia announced Python would be release for my 3650) but I just can't
seem to get on with it - it looks ugly :-)

'ugly' ??? Well, I guess this is a matter of taste (and perhaps to
exposure to languages like Haskell, Smalltalk etc, instead of just
'C-ish' syntaxes), but I'd like to understand what would make you find
Python ugly and PHP beautiful.... Not that there are no warts in Python,
but certainly less than in most scripting languages around.

Now this is OT here, so if you want to talk about it, it would be better
to move to another group (but which one ?), or keep it private.

Bruno

[Tony Marston]

"Phil Roberts" <ph*****@HOLYflatnetSHIT.net> wrote in message
news:Xn*************************@216.196.97.132...

With total disregard for any kind of safety measures "Chung Leong"
<ch***********@hotmail.com> leapt forth and uttered:

Is the OOP approach more error-prone and does it requires more
coding for typical web-programming tasks?

Nope. Because whenever I start a new site I just re-use the OO
components I developed for the last one. And if a bug gets fixed then
it gets fixed in every site.

If you do OO right first time it leads to LESS coding.

There's the crux of the matter. If you do it *right* then it should be
better, but what is the definition of *right*? Different people have
different opinions, with some of them being diametrically opposed. No matter
what you do there will always be some person of questionable parentage who
will tell you that you are wrong.

A well-written piece of code will always outperform a badly written piece of
code, and also be easier to maintain. It does not matter which one is
procedural and which one is OO. At least with PHP you can mix'n'match
between OO and procedural as you see fit, which is better than being forced
down a single route.

It does not matter which language you use, or which methodology you use, a
bad programmer will always find a way to screw up. OO just gives you newer
and better ways to screw up.

Just my 2 cents worth.

Tony Marston
http://www.tonymarston.net

[Brandon Blackmoor]

Chung Leong wrote:

Are websites built based on OOP principles inherently less
stable than those built "procedurally?"

This makes no sense. You may as well ask if automobiles constructed with
metric wrenches are are less stable than automobiles contructed with SAE
wrenches.

bblackmoor
2004-02-20

[Phil Roberts]

With total disregard for any kind of safety measures "Tony
Marston" <to**@NOSPAM.demon.co.uk> leapt forth and uttered:

There's the crux of the matter. If you do it *right* then it
should be better, but what is the definition of *right*?

"Does what I want it to".

A big part of which is re-usability.

--
Phil Roberts | Dork Pretending To Be Hard | http://www.flatnet.net/

[Chung Leong]

Uzytkownik "Tom Thackrey" <us***********@nospam.com> napisal w wiadomosci
news:VU************@newssvr27.news.prodigy.com...

Your example is too trivial. Plus the error you avoid is essentially using
an undeclared variable. I'd rather have it fail catastrophically than
subtly.

Not necessarily. The null can be returned from a function, or is an element
not set in an associative array (in $_POST for instance). In 99 out of 100
cases, the difference between null and an empty string is philosophical. The
point is, there's no data.

A more realistic example would be XML data extraction. To get an element
with a particular id, the OO code would look like:

$country = $doc->GetElementById('Poland');

while a function-based API would yield this syntax:

$country = xml_get_element_by_id($doc, 'Poland');

Now say we want to get a list of its child-elements, the OO code looks like:

$cities = $country->GetElementsByTagName('city');

while the non-OO counterpart is:

$cities = xml_get_elements_by_tag_name($country, 'city');

If there is no element with the id 'Poland', the OO could fail
castatrophically without additional safeguard, while the non-OO version
probably generates an warning (which the users probably will never see) but
does what's reasonable--prints an empty list.

[Chung Leong]

Uzytkownik "Henk Verhoeven" <ne**@metaclassREMOVE-THIS.nl> napisal w
wiadomosci news:c1**********@news4.tilbu1.nb.home.nl...

BTW, without implicit type conversion strlen(null) would have failed
too, or maybe caused a warning and returned null instead of null, which
without implicit type conversion will probably cause more problems later
on. I don't see why implicit type conversion would not be possible with
objects. In case of null->length() null could be converted to a String,
assuming the length method is only defined on String. But of course
defining length on the class of null would be more OOP ;-)

Type conversion can't take place in the case of null->Length() since it's
unclear what to convert to. Strlen() has no problem since it knows what it's
expecting. Even when a conversion is impossible (e.g. array_push(false,
true)), a function can simply do nothing. The problem with OOP in PHP is
that it essentially introduce type back into the language.

[Chung Leong]

Uzytkownik "Phil Roberts" <ph*****@HOLYflatnetSHIT.net> napisal w wiadomosci
news:Xn*************************@216.196.97.132...

Nope. Because whenever I start a new site I just re-use the OO
components I developed for the last one. And if a bug gets fixed then
it gets fixed in every site.

If you do OO right first time it leads to LESS coding.

I think you described the situation where OO isn't done right the first
time. If you have to fix bugs in the code...
reusability becomes more a liability. In the course of fixing a bug you
might introduce additional bugs, which then propagate to all your sites.
It's a possibility that can't be ruled out, so you have to retest
everything.

Again, I'm not question the merit of OO per se. Just recently I've finished
writing a beautiful class, polymorphic and all, for generating ISO images in
one project, and am now using it in another with little effort. In a given
situation, for OO to yield the promised benefit of reusability, I think the
following criteria need to be met:

* The problem has to be difficult enough to make reusing worthwhile
* The problem has to be well defined
* Solving this problem once means solving it completely--or nearly

Most of the problems you typically meet while building a site just don't
meet these criteria. They are usually on the low end of the difficulty
scale, with a large range of variations. Just think of the number of ways
you can do a select in SQL. Or how many adjustable variables there are in a
HTML table.

[Bruno Desthuilliers]

Chung Leong wrote:

Uzytkownik "Tom Thackrey" <us***********@nospam.com> napisal w wiadomosci
news:VU************@newssvr27.news.prodigy.com...

Your example is too trivial. Plus the error you avoid is essentially using
an undeclared variable. I'd rather have it fail catastrophically than
subtly.

Not necessarily. The null can be returned from a function, or is an element
not set in an associative array (in $_POST for instance). In 99 out of 100
cases, the difference between null and an empty string is philosophical. The
point is, there's no data.

The difference between null and '' is much more than just philosophical
IMHO. An empty string is not 'no data', not more than 0 is 'no data'.
A more realistic example would be XML data extraction. To get an element
with a particular id, the OO code would look like:

$country = $doc->GetElementById('Poland');

while a function-based API would yield this syntax:

$country = xml_get_element_by_id($doc, 'Poland');

Now say we want to get a list of its child-elements, the OO code looks like:

$cities = $country->GetElementsByTagName('city');

while the non-OO counterpart is:

$cities = xml_get_elements_by_tag_name($country, 'city');

If there is no element with the id 'Poland', the OO could fail
castatrophically without additional safeguard, while the non-OO version
probably generates an warning (which the users probably will never see)

(snip)

'would', 'could' etc... Why 'could' the OO version 'fail
castatrophically' and why 'would' the procedural one generate a warning?
this is just plain non-sense. The only correct behaviour *in both cases*
should be to return null, and the caller to check the return value.

If that's all your case against OO, there is no need to continue this
thread.

Bruno

[Bruno Desthuilliers]

Chung Leong wrote:

Uzytkownik "Phil Roberts" <ph*****@HOLYflatnetSHIT.net> napisal w wiadomosci
news:Xn*************************@216.196.97.132...

Nope. Because whenever I start a new site I just re-use the OO
components I developed for the last one. And if a bug gets fixed then
it gets fixed in every site.

If you do OO right first time it leads to LESS coding.

I think you described the situation where OO isn't done right the first
time. If you have to fix bugs in the code...
reusability becomes more a liability. In the course of fixing a bug you
might introduce additional bugs, which then propagate to all your sites.
It's a possibility that can't be ruled out, so you have to retest
everything.

And just what better option could the procedural approach provide ?
Again, I'm not question the merit of OO per se. Just recently I've finished
writing a beautiful class, polymorphic and all, for generating ISO images in
one project, and am now using it in another with little effort. In a given
situation, for OO to yield the promised benefit of reusability, I think the
following criteria need to be met:

* The problem has to be difficult enough to make reusing worthwhile
Oh, I see... So you'r in favor of rewrinting basic, simple functions
like strlen() for each app ?
* The problem has to be well defined
What ill-defined problem could you hope to solve, whatever the paradigm.
* Solving this problem once means solving it completely--or nearly
This has to do with reusability, not with OO.
Most of the problems you typically meet while building a site just don't
meet these criteria. They are usually on the low end of the difficulty
scale, with a large range of variations. Just think of the number of ways
you can do a select in SQL. Or how many adjustable variables there are in a
HTML table.

And ? I still fail to understand what this has to do with either OO and
stability. And BTW, you still failed to explain what support PHP offers
for modularity, except OO.

Bruno

[Bruno Desthuilliers]

Chung Leong wrote:
(snip)

The problem with OOP in PHP is
that it essentially introduce type back into the language.

Enough said. The case is hopeless...

[Henk Verhoeven]

> Type conversion can't take place in the case of null->Length()

since it's unclear what to convert to. If you have a polymorphism, it is unclear. If there is only one
implementation of Length we can let the object convert itself to that
type (assuming it can) and then call the method*.

The trouble with implicit type conversion is that it is incompatible
with polymorphism. Now polymorphisms are extendable, implicit type
conversion is not. So i prefer polymorphism. Anyhow, i agree with you
that there is a gap between OO and conventional types in php. But the
gap is a lot smaller then in Java and C++. I like that of php.

Greetings,

Henk Verhoeven.

* I can even build it in Smalltalk:

! Object methods !

doesNotUnderstand: aMessage
"If possible, convert the receiver to the implementing class and
forward to the message to it. If not, call inherited method"

| impls |
impls := Behavior implementorsOf: aMessage selector.
found size = 1 ifFalse: [^super doesNotUnderstand: aMessage].

^(aMessage receiver convertToType: found classField)
perform: aMessage selector withArguments: aMessage arguments
! !

Of course this would still fail if the conversion fails, but that
is a different problem (not an easy one though).

Chung Leong wrote: Uzytkownik "Henk Verhoeven" <ne**@metaclassREMOVE-THIS.nl> napisal w
wiadomosci news:c1**********@news4.tilbu1.nb.home.nl...

BTW, without implicit type conversion strlen(null) would have failed
too, or maybe caused a warning and returned null instead of null, which
without implicit type conversion will probably cause more problems later
on. I don't see why implicit type conversion would not be possible with
objects. In case of null->length() null could be converted to a String,
assuming the length method is only defined on String. But of course
defining length on the class of null would be more OOP ;-)

Type conversion can't take place in the case of null->Length() since it's
unclear what to convert to. Strlen() has no problem since it knows what it's
expecting. Even when a conversion is impossible (e.g. array_push(false,
true)), a function can simply do nothing. The problem with OOP in PHP is
that it essentially introduce type back into the language.

[Berislav Lopac]

Chung Leong wrote:

Now say we want to get a list of its child-elements, the OO code
looks like:

$cities = $country->GetElementsByTagName('city');

while the non-OO counterpart is:

$cities = xml_get_elements_by_tag_name($country, 'city');

If there is no element with the id 'Poland', the OO could fail
castatrophically without additional safeguard, while the non-OO
version probably generates an warning (which the users probably will
never see) but does what's reasonable--prints an empty list.

Again, you're missing the point. When you design the class that $country
object belongs to (say, class Country), you have to design the
GetElementsByTagName() method yourself. And there are several important
points here:

First, you would never call your method like that. You said "we want to get
a list of its child-elements", and from the code it appears that we want a
list of cities -- therefore, the method should be called getCities(),
because the important thing is *what* a method does (gets a list of
elements), not how. The OOP is all about finding objects in your program (in
this case, "country" is an excellent example of an object), and then
defining what properties they have and what actions (methods) can they
perform.

Second, when you write the code for your object, it would probably go
something like:

class Country {
/* snip properties, constructor and methods */

function getCities() {
return xml_get_elements_by_tag_name($this, 'city');
}
}

As you can see, here we use the exact function you mentioned in your
example, which (as you pointed out) already has a failsafe mechanism.

So, you might say, why go for OOP then, if we still use the same function?
Because if we need to change it for any reason, the object would still be
called the same way. For example, imagine that our need change, and we want
the getCities () to return not only a list of names, but an array containing
also the population of each city. Then we change the code to extract that
number as well and put it into array together with the names before
returning it. One of the basic pronciples of OOP is encapsulation, which
means that you care only about what you give to a method and what you get
from it -- what happens inside of it is completely irrelevant.

Objects are just another level of abstraction which helps _some_ programmers
organizing their code. This is also true for functions in procedural
approach (you don't really know what happens inside the
xml_get_elements_by_tag_name() function, do you), and you should use only
what is more appropriate for your approach.

Berislav

--
If the Internet is a Marx Brothers movie, and Web, e-mail, and IRC are
Groucho, Chico, and Harpo, then Usenet is Zeppo.

[Berislav Lopac]

Chung Leong wrote:

Type conversion can't take place in the case of null->Length() since
it's unclear what to convert to.
What you wrote here has absolutely no point. As NULL is not an object, it
can't have a method. And if you have an object, it cannot be NULL. So yout
moint is moot.
Strlen() has no problem since it
knows what it's expecting. Even when a conversion is impossible (e.g.
array_push(false, true)), a function can simply do nothing. The
problem with OOP in PHP is that it essentially introduce type back
into the language.

No -- it introduces classes, and classes *are* types by definition. If you
have a problem with that, fine -- don't use objects, use arrays and
functions.

Berislav

--
If the Internet is a Marx Brothers movie, and Web, e-mail, and IRC are
Groucho, Chico, and Harpo, then Usenet is Zeppo.

[Henk Verhoeven]

Berislav,

As NULL is not an object, it can't have a method.
And if you have an object, it cannot be NULL.
So yout moint is moot.
This discussion is hypothetical, but never the less,
the developers of php could have decided to make NULL an object.
Those of Smalltalk did. It's class is UndefinedObject,
nil it its only instance. "nil size" is the Smalltalk
equivalent of "null->Length()" and it returns 0.

But OK, this group is about php, and i think its developers
have created quite a nice hybrid, and php 5 will be even better.

(If only they would have been less
messy with those underscores in funcion names
(why array_reverse but strrev?)
I can never remember that...)

Greetings,

Henk Verhoeven.

Berislav Lopac wrote:
Chung Leong wrote:

Type conversion can't take place in the case of null->Length() since
it's unclear what to convert to.

What you wrote here has absolutely no point. As NULL is not an object, it
can't have a method. And if you have an object, it cannot be NULL. So yout
moint is moot.

Strlen() has no problem since it
knows what it's expecting. Even when a conversion is impossible (e.g.
array_push(false, true)), a function can simply do nothing. The
problem with OOP in PHP is that it essentially introduce type back
into the language.

No -- it introduces classes, and classes *are* types by definition. If you
have a problem with that, fine -- don't use objects, use arrays and
functions.

Berislav

--
If the Internet is a Marx Brothers movie, and Web, e-mail, and IRC are
Groucho, Chico, and Harpo, then Usenet is Zeppo.

[Chung Leong]

Uzytkownik "Berislav Lopac" <be************@dimedia.hr> napisal w wiadomosci
news:c1**********@ls219.htnet.hr...

Again, you're missing the point. When you design the class that $country
object belongs to (say, class Country), you have to design the
GetElementsByTagName() method yourself. And there are several important
points here:
No matter how you design the class, calling its method when the object isn't
instantialized will fail.

$country = null;
$country->getCities();

There's no getting around the fact that OO introduce type into PHP--hence
runtime type-mismatch errors.
So, you might say, why go for OOP then, if we still use the same function?
Because if we need to change it for any reason, the object would still be
called the same way. For example, imagine that our need change, and we want the getCities () to return not only a list of names, but an array containing also the population of each city. Then we change the code to extract that
number as well and put it into array together with the names before
returning it. One of the basic pronciples of OOP is encapsulation, which
means that you care only about what you give to a method and what you get
from it -- what happens inside of it is completely irrelevant.

I think your example is just a little off there. Having getCities() return
something else changes the class interface. If you're expecting a name plus
a population number, you clearly are not calling the method the same way. A
better OO example would have the data-source changed from XML to some other
format, a SQL database perhaps, with the application code isolated from the
backend changes...etc. etc.

Encapsulation makes sense in situation where the implementation of the
object changes often. I don't see this being the case in a typical web
project. Much more likely to change are requirements of code that would make
use of the object. As in your example, suddenly we need to display the
population of a city. If the existing interface doesn't provide that, then
you end up having to alter what--if you adhere by OO--shouldn't be altered.
In the procedural world, you just add another step to extract the population
number and print that out.

I have to say though, the projects that I work are usually light on the
backend side and very heavy on the frontend, where OO, from my experience,
tend not to work.

[Bruno Desthuilliers]

Chung Leong wrote:
(snip)

I have to say though, the projects that I work are usually light on the
backend side and very heavy on the frontend, where OO, from my experience,
tend not to work.

Yes, OO tend not to work on the frontend. That's probably why so many
GUI toolkits are clearly OO (even those written with procedural
languages like C, cf GTK+).

And if you think this has nothing to do with web developpement, think of
projects like PHPWebSite...
Bruno

[André Næss]

Chung Leong:

Uzytkownik "Berislav Lopac" <be************@dimedia.hr> napisal w
wiadomosci news:c1**********@ls219.htnet.hr...

Again, you're missing the point. When you design the class that $country
object belongs to (say, class Country), you have to design the
GetElementsByTagName() method yourself. And there are several important
points here:

No matter how you design the class, calling its method when the object
isn't instantialized will fail.

$country = null;
$country->getCities();

There's no getting around the fact that OO introduce type into PHP--hence
runtime type-mismatch errors.

PHP has always had types. But in PHP variables don't have types, values do.
I've written plenty of functions myself that expect the arguments to be
certain types, and if the values are of the wrong type an error is raised.
One thing that may confuse people into thinking PHP is somehow typeless is
all the silent type coercions that go on behind the curtain.

With OO the type system of PHP is basically enhanced with user defined
types. User defined types don't allow for the same amount of type coercion,
although I'm sure it would be possible to write code to do type coercion.

See: http://www.php.net/manual/en/language.types.php

André Næss