> > As for better OO. I think many of the things people ask for, like
> > visibility (public,private,protected) class properties, aren't actually
> > features that add functionality, but more just convenience features
> > that could be implemented in user space.
>
> I disagree. Just as with strong typing (which I hope will be added to
> PHP5 (optional - see how it's planned for Perl6)), language-enforced OO
> visibility makes it possible that the *compiler* (interpreter)
> immediately catches a bug that could hide for ages otherwise.
> Errare humanum est - conventions can't prevent mistakes.
>
This is something I've been waiting for, as well. Public, private, and
protected are definately important features as far as I'm concerned.
For instance: If a team develops a complex web application with PHP,
being careful to use naming conventions and such to resolve
public/private namespace conflicts, fine. But what happens when the team
completes their job and their contract is up; maybe in a year the
company who had the thing written wants to add some functionality, so
they once again hire a team or maybe just one programmer. However, the
programmer isn't so knowledgable about the system and before he knows it
he's got all kinds of problems with using object data that SHOULD be
protected (preceded by an _), but isn't.
I know this may not sound important, but it is. On top of that, if it
wasn't important, why would C/C++, Java, etc. all have it and stress
that it should be used instead of making everything "public"?
It's not a matter of preference; it's a matter of making classes truely
abstract types (using member functions to manipulate special data) and
not semi-abstract (you can use the functions or you can mess things up
by not using them).
Just my .02 -
--Toby
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
