On Wed, 2005-06-15 at 13:21, Rasmus Lerdorf wrote: > Andi Gutmans wrote: > > Personally, I don't think there's a significant benefit to adding > > support for public. There are so many differences and new features that > > the gain of just being able to change "var" to "public" would be > > marginal at best. > > > > That said, I don't mind supporting if people think it will help. It's a > > tiny patch and doesn't break any serious API compatibility except for > > the downside of not being able to run PHP 4.4 code on PHP 4.3 (if it > > uses public), which probably defeats the purpose of supporting both PHP > > 4 and PHP 5. > > > > Again though, we can do it... It's no biggy. > > What was the reasoning again for not having var be a synonym for public > in PHP5? It is a bit annoying that a simple PHP4 class using var throws > a notice in PHP5 when there is technically nothing wrong with it.
*hah* I was just about to ask that. Seems silly that PHP5 didn't just treat var as a public declaration. I put a dirty hack in my framework that filters warnings in the error handler related to "var" warnings. I see absolutely no reason why I should break PHP4 compatibility and maintain 2 versions of the framework because "var" generates a warning. And I refuse to develop with reduced error level (I think reducing error level is a cop out that leads to poor code). Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
