Re: Future plans (4.1) ?

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" <php-lists@imawebdesigner.com> a écrit dans le message news: 3A7B4654.D022866B@imawebdesigner.com... > > > 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: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >