On 7-May-06, at 11:53 AM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
On 7-May-06, at 11:02 AM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
I am +0 on these two extensions, hence the "to be discussed", as
long as they are not enabled by default I see no problem with
symlinking them in.
I'd like to see the json extension enabled by default. It's a
trivially small extension with no external deps and pretty much
required for modern Web apps.
That's stretching it a bit, don't you think? I don't deny that
JSON extension is useful, but "required" for modern apps, c'mon...
I can't think of anything I have written, or anybody around me has
written in the past 6 months that didn't need json. Yes, I guess
if you have no Javascript at all, then you don't need json, but if
you do any Javascript, it is the only sane way to transfer data
from PHP to Javascript. Even if you don't use Ajax-like backend
requests, a simple:
<script>
var data = <?php echo json_encode($php_data)?>;
</script>
Is so much easier, cleaner and safer than any other mechanisms you
can throw at this. The fact that we didn't get this into PHP
sooner is actually a bit sad as far as I am concerned
Well, I have written quite a few application in the past few years
and many of them have used JavaScript in one way or another and only
in few instances did the amount of data involve required something as
evolved as JSON. Every extension in PECL exists because someone out
there has a need for the functionality no matter how obscure it may
seem to the rest of us. JSON certainly seems like something that
could be of use to a large group from what I am hearing on and off
the list, so lets link it in.
And I think the filter extension should be enabled as well, but
without the default filter turned on to make the filtering
functions available.
What impact would it have on the speed of input processing if it
is always there, but not doing anything? I'd prefer to avoid
adding extra overhead for something that does nothing by default,
we have enough performance issues as is in 5.X. Pierre and Derick
are telling me that if the RAW filter is enabled it won't touch
the data so perhaps that's the route we should take, but I'd
definitely like to see before & after benchmarks.
It won't touch the data, but that doesn't mean it isn't useful.
Being able to do:
echo input_get(INPUT_SERVER, "SCRIPT_URI", FILTER_SANITIZE_URL);
or using the new input_get_args() function to completely and safely
specify all your input parameters to a page is also a big win.
Well that can still work, we can access the data from PG
(http_globals) without having to duplicate the data at the onset.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
