Paul wrote:
Здравствуйте, internals.
"From: Rasmus Lerdorf
To: internals@lists.php.net
CC: [EMAIL PROTECTED]
Subject: [PHP-DEV] JSON inclusion in core
Date: Fri, 20 Jan 2006 11:31:58 -0800
pecl/json is a rather simple extension with no external deps (it
bundles the small library it uses)
> >JavaScript does have a concept of an object in its prototype chain.
> >However, it is not captured in JSON, so the part about JSON's object
> >being just an associative array is correct.
> >
> >It makes sense to me that JSON->PHP would produce an associate array.
> >Independent of that, it mig
From the enterprise point of view I think having the JSON extension
built into PHP will bring JSON usage to the forefront of "AJAX"
development.
I've been using Omar's extension here at McAfee with great success
lately... rolling out rich UI app prototypes. Shared Host users without
access to
On Mon, Jan 23, 2006 at 06:00:24PM +0100, Pierre wrote:
>
> A "working" strip_tags, something like strip_tags_ex :)
Ah. My brain was still on the JSON part of this thread and was befuttled
by Rasmus talking about tags and attributes in relation to JSON.
Pardon,
--Dan
--
T H E A N A L Y S
> > JSON in general looks far better suited to the PHP->js layer..
>
> Yup, until browsers start sending JSON requests natively, I don't see
> much js->PHP usage either. PHP->js is the much more common
> use case at this point.
We are working on better browser support for JSON. We are develo
Alan Knowles wrote:
I'm not sure that js->PHP is that critical (in terms of getting clever
with objects etc), doing standard HTTP GET/POST requests with urlencoded
values into $_GET/$_POST, 99% of the time is far more efficient way of
sending data to the server, and alot easier to debug.. You c
I'm not sure that js->PHP is that critical (in terms of getting clever
with objects etc), doing standard HTTP GET/POST requests with urlencoded
values into $_GET/$_POST, 99% of the time is far more efficient way of
sending data to the server, and alot easier to debug.. You can also
implement th
"Bart de Boer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Bart de Boer wrote:
>> Bart
>
>
> I was wrong when I said that objects would be more consistent with the
> behaviour in JavaScript. When I said that I had the following JavaScript
> syntax in mind:
>
> object.property;
Bart de Boer wrote:
Mike Naberezny wrote:
Bart de Boer wrote:
Maybe introduce an optional second argument "decodetype" to
json_decode() where you could pass on a constant like JSON_ARRAY or
JSON_OBJECT?
For example:
$assoc_array = json_decode($json_string, JSON_ARRAY);
$object = json_d
> I guess I am confused.
> Javascript, and thus JSON, has no concept of an object.
> It has something it calls an object, but that is just an
> associative array.
> Are you trying to layer some other syntax on top of
> JSON to convey more meaning than what JSON/Javascript
> natively suppo
Mike Naberezny wrote:
Bart de Boer wrote:
Maybe introduce an optional second argument "decodetype" to
json_decode() where you could pass on a constant like JSON_ARRAY or
JSON_OBJECT?
For example:
$assoc_array = json_decode($json_string, JSON_ARRAY);
$object = json_decode($json_string, J
Bart de Boer wrote:
Maybe introduce an optional second argument "decodetype" to
json_decode() where you could pass on a constant like JSON_ARRAY or
JSON_OBJECT?
For example:
$assoc_array = json_decode($json_string, JSON_ARRAY);
$object = json_decode($json_string, JSON_OBJECT);
I'm not
On Mon, 23 Jan 2006 11:55:26 -0500
[EMAIL PROTECTED] (Daniel Convissor) wrote:
> Hi Rasmus:
>
> On Sun, Jan 22, 2006 at 03:02:02PM -0800, Rasmus Lerdorf wrote:
> >
> > A useful tag filter that understands attributes as well so you can
> > lock down exactly which tags with which attributes you wi
Hi Andi:
On Sat, Jan 21, 2006 at 08:01:25AM -0800, Andi Gutmans wrote:
>
> Well I think the right thing to do is pass an array of "allowed"
> classes into json_decode() and raise an error/exception if it's not
> in the list.
>
> I think it wasn't clear to some people why this is needed.
> I th
On Mon, 2006-01-23 at 11:55 -0500, Daniel Convissor wrote:
> Hi Rasmus:
>
> On Sun, Jan 22, 2006 at 03:02:02PM -0800, Rasmus Lerdorf wrote:
> >
> > A useful tag filter that understands attributes as well so you can lock
> > down exactly which tags with which attributes you wish to allow through.
Hi Rasmus:
On Sun, Jan 22, 2006 at 03:02:02PM -0800, Rasmus Lerdorf wrote:
>
> A useful tag filter that understands attributes as well so you can lock
> down exactly which tags with which attributes you wish to allow through.
Tags? Attributes? I can try to guess what you mean, but perhaps yo
On Sat, 21 Jan 2006, Derick Rethans wrote:
On Fri, 20 Jan 2006, Rasmus Lerdorf wrote:
I am all for the filter extension as well obviously, but I agree there is a
bit of cleanup needed and I have a bunch of things I'd like to see in it, but
none of them necessarily block adding it.
What would y
That could work. Since arrays in javascript are numeric only, one
could determine if a structure is an object or an array. However,
there are no functions to determine if an array contains associative
items, so that would have to be implemented in userland.
Being able to encode arrays to JSON
Daniel Convissor wrote:
Exactly what I was going to say.
The one thing I'd like to see change is having JSON "objects" decoded into
PHP associative arrays, not PHP objects, as is done in the current PECL
implementation. Here's what happens now via PECL JSON:
Maybe introduce an optional sec
On Sat, Jan 21, 2006 at 02:21:14PM +0100, Christian Stocker wrote:
>
> AFAIK an object in JSON is just an associative array in PHP, so I don't
> see the point here in implementing that in anything else than an
> associative array on the PHP side.
Exactly what I was going to say.
The one thing I'
On Jan 21, 2006, at 11:05 AM, Lukas Smith wrote:
Maybe we should try to come up with a common approach here for
unserialize() as well?
Along with mysql_fetch_object and its cousins? I haven't yet looked at
the __set_state magic method from var_export, but isn't another side of
the same coi
Howdy:
On Sat, Jan 21, 2006 at 01:48:54PM +0100, Derick Rethans wrote:
>
> I changed in CVS as follows:
>
> FL_* -> FILTER_VLIDATE_*
The above is a typo here only. The CVS commit is correct.
http://news.php.net/php.pecl.cvs/5003
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S
>
> At 04:25 AM 1/21/2006, Jared Williams wrote:
> >What are the security implications of doing this?
> >Creating objects based on a string from a untrusted source seems not
> >good idea, unless can prevent tampering (with an HMAC or something).
>
> Well I think the right thing to do is pass an
Andi Gutmans wrote:
At 04:25 AM 1/21/2006, Jared Williams wrote:
What are the security implications of doing this?
Creating objects based on a string from a untrusted source seems not
good idea, unless can prevent tampering (with an HMAC or
something).
Well I think the right thing to do is p
Andi Gutmans wrote:
At 04:25 AM 1/21/2006, Jared Williams wrote:
What are the security implications of doing this?
Creating objects based on a string from a untrusted source seems not
good idea, unless can prevent tampering (with an HMAC or
something).
Well I think the right thing to do is p
At 04:25 AM 1/21/2006, Jared Williams wrote:
What are the security implications of doing this?
Creating objects based on a string from a untrusted source seems not
good idea, unless can prevent tampering (with an HMAC or
something).
Well I think the right thing to do is pass an array of "allo
On Sat, 21 Jan 2006 13:30:44 -
[EMAIL PROTECTED] ("Jared Williams") wrote:
> Also it'd been nice if the requirement to have name/label in double
> quotes was removed, (I havent read a JSON spec, so it maybe correct)
> but javascript doesn't require it.
It is defined this way in the JSON spec
> AFAIK an object in JSON is just an associative array in PHP,
> so I don't see the point here in implementing that in
> anything else than an associative array on the PHP side.
>
The json extension currently creates stdClass objects.
$config = '{"windowA":
{
"left":
On 21.1.2006 13:25 Uhr, Jared Williams wrote:
>
>
>>At 06:01 PM 1/20/2006, Rasmus Lerdorf wrote:
>>
>>>Andi Gutmans wrote:
>>>
Yeah, but the main problem with this kind of stuff is when
>>
>>you start
>>
mapping classes and even references. I think it requires some
additional pl
On Fri, 20 Jan 2006, Rasmus Lerdorf wrote:
> I am all for the filter extension as well obviously, but I agree there is a
> bit of cleanup needed and I have a bunch of things I'd like to see in it, but
> none of them necessarily block adding it.
What would you like to add?
Derick
--
Derick Reth
On Sat, 21 Jan 2006, Jani Taskinen wrote:
> On Fri, 20 Jan 2006, Andi Gutmans wrote:
> > Not sure about the functionality, and I agree some of it can probably way,
> > but
>
> Way..wait? :)
>
> > I would want to finalize the naming before so that we don't have to change
> > it and have anoth
> At 06:01 PM 1/20/2006, Rasmus Lerdorf wrote:
> >Andi Gutmans wrote:
> >>Yeah, but the main problem with this kind of stuff is when
> you start
> >>mapping classes and even references. I think it requires some
> >>additional pluming to be really useful for writing robust
> >>JavaScript<-->PH
On Fri, 20 Jan 2006, Andi Gutmans wrote:
Not sure about the functionality, and I agree some of it can probably way, but
Way..wait? :)
I would want to finalize the naming before so that we don't have to change it
and have another BC mode.
If the naming is the only problem, I can fix
On 1/21/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> At 06:15 PM 1/20/2006, Rasmus Lerdorf wrote:
> >I am all for the filter extension as well obviously, but I agree
> >there is a bit of cleanup needed and I have a bunch of things I'd
> >like to see in it, but none of them necessarily block adding
At 06:15 PM 1/20/2006, Rasmus Lerdorf wrote:
I am all for the filter extension as well obviously, but I agree
there is a bit of cleanup needed and I have a bunch of things I'd
like to see in it, but none of them necessarily block adding it.
Not sure about the functionality, and I agree some of
At 06:01 PM 1/20/2006, Rasmus Lerdorf wrote:
Andi Gutmans wrote:
Yeah, but the main problem with this kind of stuff is when you
start mapping classes and even references. I think it requires some
additional pluming to be really useful for writing robust
JavaScript<-->PHP connectivity so that i
I am all for the filter extension as well obviously, but I agree there
is a bit of cleanup needed and I have a bunch of things I'd like to see
in it, but none of them necessarily block adding it.
As far as promising it for 5.1.0? I don't recall that being the case.
It wasn't ready when we rol
Andi Gutmans wrote:
Yeah, but the main problem with this kind of stuff is when you start
mapping classes and even references. I think it requires some additional
pluming to be really useful for writing robust JavaScript<-->PHP
connectivity so that it's flexible enough for all those PHP packages
At 05:17 PM 1/20/2006, Omar Kilani wrote:
Rasmus, Marcus,
Friday, January 20, 2006, 8:31:58 PM, you wrote:
pecl/json is a rather simple extension with no external deps (it
bundles the small library it uses). The JSON format is stable
with no real possibility of changing basically by definit
On 1/21/06, Omar Kilani <[EMAIL PROTECTED]> wrote:
> I've modified the license back to the PHP license in cvs.
>
> The reason I switched to the LGPL in the first place is so that Debian
> would allow inclusion of the package. :)
The debian (and other distros) problem is solved by the PHP License
Rasmus, Marcus,
Friday, January 20, 2006, 8:31:58 PM, you wrote:
pecl/json is a rather simple extension with no external deps (it bundles
the small library it uses). The JSON format is stable with no real
possibility of changing basically by definition, and I see its use
exploding this year
Yeah, but the main problem with this kind of stuff is when you start
mapping classes and even references. I think it requires some
additional pluming to be really useful for writing robust
JavaScript<-->PHP connectivity so that it's flexible enough for all
those PHP packages to start using it.
I've always been in favor of having ext/filter in standard PHP. It's
time we added some security supporting features.
Only thing I'd like to do before that is improve the naming
conventions a bit. Functions filter_* and I think the constant naming
like FL_* and FS_* is a bit confusing. But those
I'm not against this extension. I'd just very much like to
see the filter extension finally in core as was promised
for 5.1.0 once upon the time..IIRC.
--Jani
On Fri, 20 Jan 2006, Andi Gutmans wrote:
JSON is actually useful for real-world apps and not only for
buzzword-comp
On 1/21/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> JSON is actually useful for real-world apps and not only for
> buzzword-compliance :)
A release could help to get a wider audience. It is not yet available
for common users under pecl.php.net.
--Pierre
--
PHP Internals - PHP Runtime Developme
On Fri, 20 Jan 2006, Andi Gutmans wrote:
> JSON is actually useful for real-world apps and not only for
> buzzword-compliance :)
But so is pecl/filter ...
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
JSON is actually useful for real-world apps and not only for
buzzword-compliance :)
At 02:02 PM 1/20/2006, Jani Taskinen wrote:
yet-another-must-have-because-it-is-sexy-and-buzzword-compliant
extension..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:/
It's pretty simple.
string json_encode(mixed whatever)
mixed json_decode(string encoded_whatever)
It's just a serializer.
-Rasmus
Andi Gutmans wrote:
Hey,
I think having a JSON extension for PHP is a good idea. We have written
our own implementation in PHP for framework but could defini
What about pecl/filter ?!
I find that much more important and useful than any
yet-another-must-have-because-it-is-sexy-and-buzzword-compliant extension..
--Jani
On Fri, 20 Jan 2006, Andi Gutmans wrote:
Hey,
I think having a JSON extension for PHP is a good idea. We have wri
Hey,
I think having a JSON extension for PHP is a good idea. We have
written our own implementation in PHP for framework but could
definitely benefit from a C extension down the road if it gets widely adopted.
My only concern is that this is a very new extension and I haven't
seen any docs y
As long as the extension is licensed under the PHP License, I don't see
a problem with including in PHP 6.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Rasmus,
Friday, January 20, 2006, 8:31:58 PM, you wrote:
> pecl/json is a rather simple extension with no external deps (it bundles
> the small library it uses). The JSON format is stable with no real
> possibility of changing basically by definition, and I see its use
> exploding this
pecl/json is a rather simple extension with no external deps (it bundles
the small library it uses). The JSON format is stable with no real
possibility of changing basically by definition, and I see its use
exploding this year. There is also talk to a JSON Request object being
added to browse
53 matches
Mail list logo
