OOP leads to lousy websites?

[Berislav Lopac]

Re: OOP leads to lousy websites?

Chung Leong wrote:[color=blue]
> Type conversion can't take place in the case of null->Length() since
> it's unclear what to convert to.[/color]

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.
[color=blue]
> 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]

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]

Re: OOP leads to lousy websites?

Berislav,
[color=blue]
> 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.[/color]

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:
[color=blue]
> Chung Leong wrote:
>[color=green]
>>Type conversion can't take place in the case of null->Length() since
>>it's unclear what to convert to.[/color]
>
>
> 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.
>
>[color=green]
>>Strlen() has no problem since it
>>knows what it's expecting. Even when a conversion is impossible (e.g.
>>array_push(fa lse, true)), a function can simply do nothing. The
>>problem with OOP in PHP is that it essentially introduce type back
>>into the language.[/color]
>
>
> 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.
>
>[/color]

[Chung Leong]

Re: OOP leads to lousy websites?

Uzytkownik "Berislav Lopac" <berislav.lopac @dimedia.hr> napisal w wiadomosci
news:c1ceib$cd2 $1@ls219.htnet. hr...[color=blue]
> 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:[/color]

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.
[color=blue]
> 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[/color]
want[color=blue]
> the getCities () to return not only a list of names, but an array[/color]
containing[color=blue]
> 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.[/color]

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]

Re: OOP leads to lousy websites?

Chung Leong wrote:
(snip)[color=blue]
> 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.
>[/color]

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]

Re: OOP leads to lousy websites?

Chung Leong:
[color=blue]
> Uzytkownik "Berislav Lopac" <berislav.lopac @dimedia.hr> napisal w
> wiadomosci news:c1ceib$cd2 $1@ls219.htnet. hr...[color=green]
>> 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:[/color]
>
> 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.[/color]

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