Hi,
I think this kind of reflection particularly holds true when thinking about
OpenSource development, where a potentially unlimited number of developers
all work on the same project; developers from all over the world. Now, how
would you possibly try to impose a coding standard to several dozens of
people coming from different countries, having different backgrounds, etc
etc.
"Toby Butzon" <[EMAIL PROTECTED]> a écrit dans le message news:
[EMAIL PROTECTED]
> > > 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]
>
--
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]
