On Thu, 26 Jul 2001, Zeev Suraski wrote:
> >But in this case someone has gone to the trouble to figure out what
> >empty() does. And generally they use empty() on things that come from the
> >user anyway. I don't think I have ever seen people use empty() to check
> >to see if they themselves have set an internal variable to something.
> I have... And quite a lot use isset(), which is much more common and
> popular than empty().
I use both isset() and empty() in hundreds of lines of code that check
my own internally defined structures, such as predefined arrays that define
behaviour of the code.
> I actually think that turning E_NOTICE on is going to have a huge effect on
> a mind boggling number of scripts, probably on the same order of magnitude
> as setting register_globals to off (probably less, but not that much
> less).
One major problem I'm currently having is that I like to reuse
other people's PHP code if any is available, and I have to hack up
a horrible number of directory- and virtual host-specific error_reporting
values because the code otherwise generates megabytes of log over a very
short while.
This makes it extremely hard to maintain a codebase that uses both
our own and others' code where our code is strictly developed against
E_NOTICE and others' will have to either be reviewed thoroughly or
constrained in a shell where different rules apply.
I've been told that E_NOTICE generates warnings that you would have
to bypass by making things more complicately and that this would
hurt one of the greatest advantages of the language: flexibility.
This does, of course, hold some truth, but I think that time and
experience has shown that this specific flexibility (E_NOTICE and
register_globals) causes too much damage and has too many security
implications to be left as is. Unexperienced programmers should be
given defaults that guide them in a right direction with good
programming practices, and leave the advanced flexibility options to
more experienced programmers.
> No doubt, this would cause many
> (perhaps even most) PHP applications out there not to install out of the
> box, but I think that setting register_globals off is a pretty pressing
> matter, and without some pain (i.e., forcing app authors to update their
> apps to work with the track_vars arrays) we won't get anywhere.
Maintaining backward compatibility at all costs has made Perl what it
is today. I've been happy that PHP has this far not taken this matter
to such limits.
> Zeev
--
<---------------------------------------------------------------------->
Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/
--
PHP Development 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]
