Hi,
On Fri, 12 Aug 2005 10:48:20 -0700, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
>Since we are breaking a lot of stuff in 6.0, at least with
>Unicode_semantics=On I am wondering if it may not be time to break some
>more stuff and do a bit of spring cleaning. It would mean many apps
>would need some work to work on PHP 6, but at the same time I think it
>is work people would welcome since it would mostly involve removing
>hacks instead of adding them. And yes, I know this is pretty
>controversial, so take a few deep breaths before replying, please.
I know this is just a wish list, and it wouldn't be constructive to go
into implementation details. As you said, this is cleanup where some
eggs will have to break.
FWIW, as many others, I'm mainly positive about all the changes. Not
surprisingly there would be a bunch of work regarding the information
to end users. This might require some political decisions on what to
recommend, when "features" are removed from users.
I'll go into details here:
>1. Remove register_globals completely
>
>2. Remove magic_quotes_*
I'm all for. It would be nice, though, to provide users with details
on how to do it "the right way" regarding database queries.
Even though there are a lot of ways of doing it (manually call
mysql_real_escape_string, use PEAR DB, use another API, etc.)., it
might be nice to show users a simple way of doing stuff. I really like
the perl DBI which is the de facto way of doing database work. I
believe that lots of stuff that DBI (and PEAR DB and other DB
abstraction layers) provide is helpful. Crafting and concatenating a
query string really is a mess.
On one hand this might have nothing to do with the tools and more on
recommendations on how to code. It might not be the job of the PHP
team to teach users how to code or recommend specific ways to code
(think of all the OOP- and exception handling-discussions).
Furthermore people might have different views on what API to use. I
like PEAR DB because it is widely used, but as an example I don't like
the chicken-and-the-egg problem (DB_common only gets read when
DB::Connect has been called and loaded, så DB_common can't be
extended). The point is mainly that it would be hard to recommend one
way of doing things now (and it might be a political decision as
well).
On the other hand, people will be in demand of
"how-to-convert"-information in the transitional phase. And if we
really are doing a spring cleanup, we might consider doing it on the
users as well :-)
>3. Add input filter extension which will include a mechanism for
> application developers to very easily turn it off which would swap
> the raw GPC arrays back in case the site had it turned on by default.
This might go in hand with the first two wishes. It would be nice to
make it easy for users who write php code that are going to be
distributed world wide on different configurations without going into
hundreds of different checks (such as "if (get_magic_quotes_gpc()) {
.. }" ).
>5. Remove safe_mode and focus on open_basedir
I think a lot of work would have to go into this. Currently <warning
type="pet peeve"> it could partially be circumvented using glob, e.g.
print_r(glob("{/home/currentuser/,/etc}/*",GLOB_BRACE)); or error
harvesting ("File(/tmp/sess_1234567890) is not within the allowed
path(s)") </warning>
I'm not sure whether or not this is regarded as a problem. These
issues have been dismissed on the bugs list and I haven't heard
anything from [EMAIL PROTECTED]
Another type of default session handler might also be nice without
direct mapping of file names and session ids - e.g. hashed values and
addition of hashed SERVER_NAME where available.
Regarding the way users code (as mentioned in #3), we also see that
when notices were enabed and widespread on installations, e.g.:
if ($_REQUEST['foo'] == ...)
.. users just changed their code to:
if (isset($_REQUEST['foo']) && $_REQUEST['foo'] == ...)
I don't think this is particular more nice code, but just a recurring
pattern every time a variable from the outside is submitted. This is a
really wild idea, but how about retrieving external variables using
functions instead? The idea is that external data isn't variables per
default and could be referenced without throwing notices, e.g.:
if (getuserdata('foo') == ...)
Of course I'm not against notices, but I think there is a clear
distinction (or should be...) between stuff that might exist beyond
our control (user-submitted data) and stuff that we rely on (own
variables).
But all in all: very exciting. As mentioned, there really might be a
lot of work regarding the information and transitional help if all
these wishes come true.
--
- Peter Brodersen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
