OOP leads to lousy websites?

[Chung Leong]

Re: OOP leads to lousy websites?

Uzytkownik "rush" <pipa@rush.aval on.hr> napisal w wiadomosci
news:c11tc4$8qt $1@ls219.htnet. hr...[color=blue]
> I do not think website app programming is very different from any other[/color]
kind[color=blue]
> 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.[/color]

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.
[color=blue]
> as for reliability, for me OO makes it easier to make code of better[/color]
quality[color=blue]
> 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.[/color]

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]

Re: OOP leads to lousy websites?

<snip>[color=blue]
> OO makes it easier to make code look better than it actually is.
> Encapsulation, more often than not, means stuffing sphaghetti into a
> blackbox.[/color]

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]

Re: OOP leads to lousy websites?

With total disregard for any kind of safety measures "Chung Leong"
<chernyshevsky@ hotmail.com> leapt forth and uttered:
[color=blue]
> Is the OOP approach more error-prone and does it requires more
> coding for typical web-programming tasks?
>[/color]

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]

Re: [OT] OOP leads to lousy websites?

Andy Jeffries wrote:[color=blue]
> Bruno Desthuilliers wrote:
>[color=green]
>> (snip the rest, on which I globally agree !-)[/color]
> Jolly good... :-)
>[color=green][color=darkred]
>>> I think PHP achieves a mix of structured and OO programming with
>>> unparalled excellence....[/color]
>>
>> <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>[/color]
>
> <joking trolling>
> Yeah, but I don't like the idea of programming in languages where
> indentation affects how the program runs.
> </joking trolling>[/color]

Don't you indent your code anyway ? Seriously, I *never* had a problem
with this in four years.
[color=blue]
> 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 :-)[/color]

'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]

Re: OOP leads to lousy websites?


"Phil Roberts" <philrob@HOLYfl atnetSHIT.net> wrote in message
news:Xns949550E F72DC8philrober ts@216.196.97.1 32...[color=blue]
> With total disregard for any kind of safety measures "Chung Leong"
> <chernyshevsky@ hotmail.com> leapt forth and uttered:
>[color=green]
> > Is the OOP approach more error-prone and does it requires more
> > coding for typical web-programming tasks?
> >[/color]
>
> 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.
>[/color]

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]

Re: OOP leads to lousy websites?

Chung Leong wrote:[color=blue]
>
> Are websites built based on OOP principles inherently less
> stable than those built "procedural ly?"[/color]

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]

Re: OOP leads to lousy websites?

With total disregard for any kind of safety measures "Tony
Marston" <tony@NOSPAM.de mon.co.uk> leapt forth and uttered:
[color=blue]
> There's the crux of the matter. If you do it *right* then it
> should be better, but what is the definition of *right*?[/color]

"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]

Re: OOP leads to lousy websites?

Uzytkownik "Tom Thackrey" <use.signature@ nospam.com> napisal w wiadomosci
news:VUcZb.21$0 A2.5@newssvr27. news.prodigy.co m...[color=blue]
> Your example is too trivial. Plus the error you avoid is essentially using
> an undeclared variable. I'd rather have it fail catastrophicall y than
> subtly.[/color]

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->GetElementsByT agName('city');

while the non-OO counterpart is:

$cities = xml_get_element s_by_tag_name($ country, 'city');

If there is no element with the id 'Poland', the OO could fail
castatrophicall y 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]

Re: OOP leads to lousy websites?

Uzytkownik "Henk Verhoeven" <news@metaclass REMOVE-THIS.nl> napisal w
wiadomosci news:c13mvh$e3i $1@news4.tilbu1 .nb.home.nl...[color=blue]
> 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 ;-)[/color]

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(fals e,
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]

Re: OOP leads to lousy websites?

Uzytkownik "Phil Roberts" <philrob@HOLYfl atnetSHIT.net> napisal w wiadomosci
news:Xns949550E F72DC8philrober ts@216.196.97.1 32...[color=blue]
> 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.[/color]

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]

Re: OOP leads to lousy websites?

Chung Leong wrote:[color=blue]
> Uzytkownik "Tom Thackrey" <use.signature@ nospam.com> napisal w wiadomosci
> news:VUcZb.21$0 A2.5@newssvr27. news.prodigy.co m...
>[color=green]
>>Your example is too trivial. Plus the error you avoid is essentially using
>>an undeclared variable. I'd rather have it fail catastrophicall y than
>>subtly.[/color]
>
>
> 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.[/color]

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'.
[color=blue]
> 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->GetElementsByT agName('city');
>
> while the non-OO counterpart is:
>
> $cities = xml_get_element s_by_tag_name($ country, 'city');
>
> If there is no element with the id 'Poland', the OO could fail
> castatrophicall y without additional safeguard, while the non-OO version
> probably generates an warning (which the users probably will never see)[/color]
(snip)

'would', 'could' etc... Why 'could' the OO version 'fail
castatrophicall y' 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]

Re: OOP leads to lousy websites?

Chung Leong wrote:[color=blue]
> Uzytkownik "Phil Roberts" <philrob@HOLYfl atnetSHIT.net> napisal w wiadomosci
> news:Xns949550E F72DC8philrober ts@216.196.97.1 32...
>[color=green]
>>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.[/color]
>
>
> 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.[/color]

And just what better option could the procedural approach provide ?
[color=blue]
> 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[/color]

Oh, I see... So you'r in favor of rewrinting basic, simple functions
like strlen() for each app ?
[color=blue]
> * The problem has to be well defined[/color]

What ill-defined problem could you hope to solve, whatever the paradigm.
[color=blue]
> * Solving this problem once means solving it completely--or nearly[/color]

This has to do with reusability, not with OO.
[color=blue]
> 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.[/color]

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]

Re: OOP leads to lousy websites?

Chung Leong wrote:
(snip)[color=blue]
> The problem with OOP in PHP is
> that it essentially introduce type back into the language.[/color]

Enough said. The case is hopeless...

[Henk Verhoeven]

Re: OOP leads to lousy websites?

> Type conversion can't take place in the case of null->Length()[color=blue]
> since it's unclear what to convert to.[/color]
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 !

doesNotUndersta nd: 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 doesNotUndersta nd: 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:[color=blue]
> Uzytkownik "Henk Verhoeven" <news@metaclass REMOVE-THIS.nl> napisal w
> wiadomosci news:c13mvh$e3i $1@news4.tilbu1 .nb.home.nl...
>[color=green]
>>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 ;-)[/color]
>
>
> 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(fals e,
> true)), a function can simply do nothing. The problem with OOP in PHP is
> that it essentially introduce type back into the language.
>
>[/color]

[Berislav Lopac]

Re: OOP leads to lousy websites?

Chung Leong wrote:[color=blue]
> Now say we want to get a list of its child-elements, the OO code
> looks like:
>
> $cities = $country->GetElementsByT agName('city');
>
> while the non-OO counterpart is:
>
> $cities = xml_get_element s_by_tag_name($ country, 'city');
>
> If there is no element with the id 'Poland', the OO could fail
> castatrophicall y 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.[/color]

Again, you're missing the point. When you design the class that $country
object belongs to (say, class Country), you have to design the
GetElementsByTa gName() 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_element s_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_element s_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.