Hi,
On Aug 30, 2024 at 16:47:43, Claude Pache wrote:
>
> Note that the issue is not limited to Generators. For instance a Closure
> object is also json-encodable but not serialisable.
>
> IMO, every internal class (not just Generator) that is marked as
> non-serialisable, should also be non-js
> Le 30 août 2024 à 09:36, Philip Hofstetter a
> écrit :
>
> Hello,
>
> In the aftermath of an internal refactoring of an internal code-base to turn
> something eager into something more lazy using Generators, it occurred to me
> that while PHP refuses to serialize() a Generator, accidenta
On Fri, Aug 30, 2024 at 12:19 PM Philip Hofstetter
wrote:
>
> Username is pilif
RFC karma was granted. Good luck with the RFC!
Hi John,
On Aug 30, 2024 at 09:42:05, John Coggeshall
wrote:
> This seems entirely reasonable and I would welcome an RFC for it (unless
> someone has a better idea as to how to handle this case).
>
>
The other options I considered were to either materialize the Generator,
but given that they c
Hi Ilija,
On Aug 30, 2024 at 09:49:14, Ilija Tovilo wrote:
>
> To grant you RFC karma, I need to know your wiki.php.net username.
>
Username is pilif
Thank you
Philip Hofstetter
Hi Philip
On Fri, Aug 30, 2024 at 9:37 AM Philip Hofstetter
wrote:
>
> If you think this is a worthwhile thing to do an RFC for, I would kindly ask
> for somebody to grant me RFC karma, so I can start working on one.
To grant you RFC karma, I need to know your wiki.php.net username.
Ilija
On 03/06/2021 18:03, Timon de Groot wrote:
On 3-6-2021 17:53, Ayesh Karunaratne wrote:
Hi Timon,
Thank you for this RFC. I think the `string|int $indent` approach is
great 🚀!
Reading the PR, it looks like `$indent=0` is essentially turning off
pretty-print, which I think is intuitive.
Basical
On 3-6-2021 17:53, Ayesh Karunaratne wrote:
Hi Timon,
Thank you for this RFC. I think the `string|int $indent` approach is great 🚀!
Reading the PR, it looks like `$indent=0` is essentially turning off
pretty-print, which I think is intuitive.
Basically, yes. With `$indent=0`, no indentation will
Hi Timon,
Thank you for this RFC. I think the `string|int $indent` approach is great 🚀!
Reading the PR, it looks like `$indent=0` is essentially turning off
pretty-print, which I think is intuitive.
Do you plan to add any sort of validation on negative integers?
Perhaps throw a `\ValueError` exce
On 3-6-2021 16:15, G. P. B. wrote:
That's incorrect, as of PHP 8.0 Fast ZPP has a way to deal with the most
common union types, including int|string.
Best regards,
George P. Banyard
I found that STR_OR_LONG works fine, thanks for acknowledging!
--
Kind regards,
Timon de Groot
--
PHP Inter
On Thu, 3 Jun 2021 at 11:49, Timon de Groot wrote:
> On 3-6-2021 10:00, Jordi Boggiano wrote:
> > I agree, but I'd make it accept a string|int much like JSON.stringify
> > does, because that way you let people pass in tabs too, or "🚀" if
> > that's how you want your JSON indented..
>
> I like the
Hello,
I have seen a similar discussion for var_export(), and the answer was
basically "use a regex". E.g.:
$json = preg_replace_callback(
'/^(?: {4})+/m',
fn ($m) => str_repeat($indent, strlen($m[0]) / 4),
json_encode($data, JSON_PRETTY_PRINT)
);
That said, I wou
On 3-6-2021 10:00, Jordi Boggiano wrote:
I agree, but I'd make it accept a string|int much like JSON.stringify
does, because that way you let people pass in tabs too, or "🚀" if
that's how you want your JSON indented..
I like the idea of accepting string|int.
Accepting string|int means a zval
So if you do go ahead and make an RFC for this, I think my preference
would be as a new parameter on json_encode accepting a positive integer.
Thank your for your input, I'll start working on an RFC to introduce a
new parameter for json_encode.
--
PHP Internals - PHP Runtime Development Ma
On 03/06/2021 02:45, David Gebler wrote:
I would say though (a) is true enough but doesn't necessarily cover
all use
cases, adds more magic constants and doesn't provide equivalence to the
JSON libraries of other common languages which permit for custom values,
while (b) is less of an issue with
On Wed, 2 Jun 2021, 23:03 Timon de Groot, wrote:
> It's not possible to tell json_encode what indentation level should be
> used when using
> the JSON_PRETTY_PRINT option (2, 4, 8, etc). When generating JSON files
> which can be
> used/read/edited by users, indentation starts to become a relevant
Em qua, 4 de jul de 2018 19:01, Nikita Popov
escreveu:
> On Fri, Jun 29, 2018 at 8:51 PM, David Rodrigues
> wrote:
>
>> Hello. I saw that JS supports the x-notation (\x40) and u-notation
>> (\u0040), but PHP only supports u-notation. There some reason for that?
>>
>> JSON.parse('"\x40"'); // =>
On Fri, Jun 29, 2018 at 8:51 PM, David Rodrigues
wrote:
> Hello. I saw that JS supports the x-notation (\x40) and u-notation
> (\u0040), but PHP only supports u-notation. There some reason for that?
>
> JSON.parse('"\x40"'); // => @
> JSON.parse('"\u0040"'); // => @
>
No it doesn't. JSON.parse(
On Fri, Jun 29, 2018 at 1:51 PM, David Rodrigues wrote:
> Hello. I saw that JS supports the x-notation (\x40) and u-notation
> (\u0040), but PHP only supports u-notation. There some reason for that?
>
The TL;DR version AIUI, is that JSON strings are Unicode strings, so
any byte sequence in a JSON
Jakub Zelenka wrote:
On Sat, Jul 29, 2017 at 7:10 PM, Niklas Keller wrote:
Andrea Faulds schrieb am Sa., 29. Juli 2017, 18:55:
Hi Craig,
Craig Duncan wrote:
On 29 July 2017 at 15:16, Andrea Faulds wrote:
Could we not simply make it a flag? e.g.
$bar = json_encode($foo, JSON_THROW_
On Sat, Jul 29, 2017 at 7:10 PM, Niklas Keller wrote:
> Andrea Faulds schrieb am Sa., 29. Juli 2017, 18:55:
>
> > Hi Craig,
> >
> > Craig Duncan wrote:
> > > On 29 July 2017 at 15:16, Andrea Faulds wrote:
> > >
> > >> Could we not simply make it a flag? e.g.
> > >>
> > >> $bar = json_encode
Andrea Faulds schrieb am Sa., 29. Juli 2017, 18:55:
> Hi Craig,
>
> Craig Duncan wrote:
> > On 29 July 2017 at 15:16, Andrea Faulds wrote:
> >
> >> Could we not simply make it a flag? e.g.
> >>
> >> $bar = json_encode($foo, JSON_THROW_EXCEPTIONS);
> >> $baz = json_decode($bar, false, 512
Hi Craig,
Craig Duncan wrote:
On 29 July 2017 at 15:16, Andrea Faulds wrote:
Could we not simply make it a flag? e.g.
$bar = json_encode($foo, JSON_THROW_EXCEPTIONS);
$baz = json_decode($bar, false, 512, JSON_THROW_EXCEPTIONS);
That wouldn't break backwards-compatibility, but would
On 29 July 2017 at 15:16, Andrea Faulds wrote:
> Could we not simply make it a flag? e.g.
>
> $bar = json_encode($foo, JSON_THROW_EXCEPTIONS);
> $baz = json_decode($bar, false, 512, JSON_THROW_EXCEPTIONS);
>
> That wouldn't break backwards-compatibility, but would still provide the
> desi
Hi everyone,
Andrea Faulds wrote:
Craig Duncan wrote:
On 27 July 2017 at 16:57, Niklas Keller wrote:
It should rather just throw exceptions. Warnings do not really allow
error
handling, they just allow error reporting.
Agreed, but I can't see Exceptions passing the vote. Warnings can be
s
Hi Duncan,
Craig Duncan wrote:
On 27 July 2017 at 16:57, Niklas Keller wrote:
It should rather just throw exceptions. Warnings do not really allow error
handling, they just allow error reporting.
Agreed, but I can't see Exceptions passing the vote. Warnings can be
silenced by those that do
On 7/28/2017 3:03 AM, Ryan Jentzsch wrote:
I can't count how many times I've been bitten by this. From the infamous
fractal blog:
"Parts of PHP are practically designed to produce buggy code.
json_decode returns null for invalid input, even though null is also a
perfectly valid object for JSON t
I can't count how many times I've been bitten by this. From the infamous
fractal blog:
"Parts of PHP are practically designed to produce buggy code.
json_decode returns null for invalid input, even though null is also a
perfectly valid object for JSON to decode to—this function is completely
unrel
2017-07-28 8:56 GMT+02:00 Giovanni Giacobbi :
> On 27 July 2017 at 18:00, Craig Duncan wrote:
>
>> On 27 July 2017 at 16:57, Niklas Keller wrote:
>>
>> > It should rather just throw exceptions. Warnings do not really allow
>> error
>> > handling, they just allow error reporting.
>> >
>> >
>> Agr
On 27 July 2017 at 18:00, Craig Duncan wrote:
> On 27 July 2017 at 16:57, Niklas Keller wrote:
>
> > It should rather just throw exceptions. Warnings do not really allow
> error
> > handling, they just allow error reporting.
> >
> >
> Agreed, but I can't see Exceptions passing the vote. Warnings
On 27 July 2017 at 16:57, Niklas Keller wrote:
> It should rather just throw exceptions. Warnings do not really allow error
> handling, they just allow error reporting.
>
>
Agreed, but I can't see Exceptions passing the vote. Warnings can be
silenced by those that don't care and converted to Exce
2017-07-27 17:41 GMT+02:00 Craig Duncan :
> Hi internals,
>
> When using `json_encode()` and `json_decode()` it is required that you
> manually check for errors after every call, eg:
>
> ```php
> $data = json_decode("false");
> if (json_last_error() !== JSON_ERROR_NONE) {
> throw new Unexpecte
On Wed, Jun 27, 2012 at 2:19 PM, Nikita Popov wrote:
> I looked at a few other error functions (of which we by the way we
> have *loads*, which is a bad sign) and indeed it seems that they all
> use a separate function to get the error message. Most use a
> xyz_errno() + xyz_error() pair.
>
> So i
On Wed, Jun 27, 2012 at 1:40 PM, Pierre Joye wrote:
> hi,
>
> On Wed, Jun 27, 2012 at 1:30 PM, Nikita Popov
> wrote:
>
>>> Why not in the spirit of others have a new function json_last_error_msg() or
>>> something similar?
>>
>> I implemented it with json_last_error(true) returning just a string
hi,
On Wed, Jun 27, 2012 at 1:30 PM, Nikita Popov wrote:
>> Why not in the spirit of others have a new function json_last_error_msg() or
>> something similar?
>
> I implemented it with json_last_error(true) returning just a string,
> not an array. You can get the array using array(json_last_erro
On Wed, Jun 27, 2012 at 1:27 PM, Benjamin Eberlei wrote:
>
> On Wed, Jun 27, 2012 at 1:41 AM, Stas Malyshev
> wrote:
>>
>> Hi!
>>
>> > Makes sense to me. So should I do this? Remove warnings + add string
>> > parameter for json_last_error?
>
>
> I think its weird that the parameter is called $err
On Wed, Jun 27, 2012 at 1:41 AM, Stas Malyshev wrote:
> Hi!
>
> > Makes sense to me. So should I do this? Remove warnings + add string
> > parameter for json_last_error?
>
I think its weird that the parameter is called $error_string and setting it
to true means returning an array.
Why not in the
Hi!
> Makes sense to me. So should I do this? Remove warnings + add string
> parameter for json_last_error?
Looks fine.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
On Sun, Jun 24, 2012 at 5:39 PM, Rasmus Lerdorf wrote:
> So how about:
>
> mixed json_last_error ( [bool $error_string = false] )
>
> Returns the last error (if any) occurred during the last JSON
> encoding/decoding. By default an integer constant from the table below
> is returned. If $error_stri
On 06/24/2012 05:12 AM, Nikita Popov wrote:
> The main problem with not throwing a warning is that it makes
> debugging the error quite hard. json_last_error() only gives you an
> error code. So you have to use some script like the one used as an
> example in php.net/json_last_error to figure out w
Hola:
On Sat, Jun 23, 2012 at 06:03:34PM -0700, Rasmus Lerdorf wrote:
> And yes, I don't think a warning from json_encode() is useful because to
> properly avoid it you would need an iconv() call before calling it and
> that is pure overhead. Short of that your only recourse is to use @ and
> that
On Sun, Jun 24, 2012 at 12:50 AM, Gustavo Lopes wrote:
> If json_encode() is not supposed to receive badly encoded data, then it's
> the application writer's responsibility to make sure that the data is
> correctly encoded. If, on the other hand, you think that's actually not a
> error on the part
On 06/23/2012 04:06 PM, Stas Malyshev wrote:
> Hi!
>
>> Maybe it is simply time to rethink the error handling.
>
> This is true, current error handling has many deficiencies and is also
> very expensive even when the errors are muted (we still produce the
> whole error string, etc. even if we nev
Hi!
> Maybe it is simply time to rethink the error handling.
This is true, current error handling has many deficiencies and is also
very expensive even when the errors are muted (we still produce the
whole error string, etc. even if we never display it). Unfortunately, BC
concerns prevailed last
On Sun, 2012-06-24 at 00:24 +0200, Nikita Popov wrote:
> Yes, I feel like we must discuss this a thousand times anew. There
> clearly is no consensus about it. Just look at the responses in this
> thread and in other discussions relating this issue. When people read
> "throws a warning, but only if
On Sat, 23 Jun 2012 21:53:01 +0200, Stas Malyshev
wrote:
Hi!
The warning for invalid UTF-8 stays intact and is thrown also with
display_errors = On. If this behavior is undesired this can be remedied
later.
Must we discuss it 1000 times anew? There was a reason why it didn't
throw warning
On Sat, Jun 23, 2012 at 9:53 PM, Stas Malyshev wrote:
> Hi!
>
>> The warning for invalid UTF-8 stays intact and is thrown also with
>> display_errors = On. If this behavior is undesired this can be remedied
>> later.
>
> Must we discuss it 1000 times anew? There was a reason why it didn't
> throw
On Sat, Jun 23, 2012 at 9:53 PM, Stas Malyshev wrote:
> Hi!
>
> > The warning for invalid UTF-8 stays intact and is thrown also with
> > display_errors = On. If this behavior is undesired this can be remedied
> > later.
>
> Must we discuss it 1000 times anew? There was a reason why it didn't
> thr
Hi!
> The warning for invalid UTF-8 stays intact and is thrown also with
> display_errors = On. If this behavior is undesired this can be remedied
> later.
Must we discuss it 1000 times anew? There was a reason why it didn't
throw warning when display_errors is on. The reason is that it is very
e
I applied a few changes in
https://github.com/php/php-src/commit/84fe2cc890e49f40bac7c3ba74b3cfc6dc4cef2f
and
https://github.com/php/php-src/commit/36fa17a5fae84ab332366a202f0a709279a2466a.
>From the commit message:
<
json_encode() now returns bool(false) for all possible errors, throws the
r
>
> The problem with a warning here is that there is usually no way to
> prevent it short of using @ or preceding all calls to htmlspecialchars()
> with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a
> web app and look for that warning to get a really good idea about the
> serv
hi Rasmus,
On Thu, Jun 21, 2012 at 5:33 PM, Rasmus Lerdorf wrote:
> The problem with a warning here is that there is usually no way to
> prevent it short of using @ or preceding all calls to htmlspecialchars()
> with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a
> web app a
On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
wrote:
> Hi Nikita:
>
>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>> string is encountered:
>> * A warning is thrown, but only if display_errors=off
>
> So the warning is put into the error log? But only if display_e
On 06/21/2012 07:25 AM, Nikita Popov wrote:
> On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
> wrote:
>> Hi Nikita:
>>
>>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>>> string is encountered:
>>> * A warning is thrown, but only if display_errors=off
>>
>> So the wa
On Thu, Jun 21, 2012 at 10:25 PM, Nikita Popov
wrote:
> On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
> wrote:
>> Hi Nikita:
>>
>>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>>> string is encountered:
>>> * A warning is thrown, but only if display_errors=off
>>
>
On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
wrote:
> Hi Nikita:
>
>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>> string is encountered:
>> * A warning is thrown, but only if display_errors=off
>
> So the warning is put into the error log? But only if display_e
Hi Nikita:
> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
> string is encountered:
> * A warning is thrown, but only if display_errors=off
So the warning is put into the error log? But only if display_errors is
off? And if display_errors is on, no warning is produced?
hi,
On Thu, Jun 21, 2012 at 11:21 AM, Nikita Popov
wrote:
>> 5.3 should be brought in line with 5.4.
> So you think that the corrected code should be backed out from PHP 5.3
> and the incorrect 5.4/master behavior be restored?
For the warning yes. For the rest, it should imo return false as wel
On Thu, Jun 21, 2012 at 8:47 AM, Pierre Joye wrote:
>> The reason for this situation is that a patch was applied for all
>> branches, and then reverted, because Stas didn't consider the change
>> towards always throwing a warning (even with display_errors=on)
>> appropriate without further discuss
On Thu, Jun 21, 2012 at 2:47 PM, Pierre Joye wrote:
> hi,
>
> On Thu, Jun 21, 2012 at 12:21 AM, Nikita Popov
> wrote:
>
>> We currently have a big mess concerning the behavior of json_encode()
>> with incorrectly encoded UTF-8 strings.
>>
>> To summarize the situation:
>>
>> PHP <= 5.3.13, PHP 5.
hi,
On Thu, Jun 21, 2012 at 12:21 AM, Nikita Popov
wrote:
> We currently have a big mess concerning the behavior of json_encode()
> with incorrectly encoded UTF-8 strings.
>
> To summarize the situation:
>
> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
> string is encou
On Tue, Apr 3, 2012 at 9:46 AM, Rasmus Lerdorf wrote:
> On 04/02/2012 06:35 PM, Charlie Somerville wrote:
>> Hi internals,
>>
>> I've created a pull request (https://github.com/php/php-src/pull/33) that
>> changes json_encode to fall back to ASCII for strings that are not valid
>> UTF-8.
>>
>> I
On 3 April 2012 09:46, Rasmus Lerdorf wrote:
> On 04/02/2012 06:35 PM, Charlie Somerville wrote:
>> I've created a pull request (https://github.com/php/php-src/pull/33) that
>> changes json_encode to fall back to ASCII for strings that are not valid
>> UTF-8.
>>
>> I ran into an issue in a produ
On 04/02/2012 06:35 PM, Charlie Somerville wrote:
> Hi internals,
>
> I've created a pull request (https://github.com/php/php-src/pull/33) that
> changes json_encode to fall back to ASCII for strings that are not valid
> UTF-8.
>
> I ran into an issue in a production application involving PayP
Richard Quadling wrote:
> 2008/12/16 Robin Burchell :
>> Settings which change behaviour like that aren't really all that fun
>> for third party/portable applications developers, e.g. forum software
>> and the likes. magic_quotes_gpc and others are good examples of this.
>>
>> Going back to Rasmus'
On Wed, Dec 17, 2008 at 1:05 PM, Richard Quadling
wrote:
> Considering json_encode() COULD encode non JSON compliant data, should
> json_decode() also decode non JSON compliant data?
it should decode as much as it can without any warnings (as long, as
there's no ambiguity)
--
Alexey Zakhlestin
2008/12/16 Robin Burchell :
> Settings which change behaviour like that aren't really all that fun
> for third party/portable applications developers, e.g. forum software
> and the likes. magic_quotes_gpc and others are good examples of this.
>
> Going back to Rasmus' mail based on his discussion w
The proposed solution (basic types flag) is probably the lesser evil,
but I still feel were are taking things to far and current operation
is correct.
On 16-Dec-08, at 6:57 AM, Scott MacVicar wrote:
Richard Quadling wrote:
2008/12/15 mike :
On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf
1. Document the fact that if you want to strictly conform to the JSON
spec and be sure your json_encode output will work in various JSON
parsers, you have to pass it a PHP array or object.
+1
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Mon, Dec 15, 2008 at 6:50 PM, Rasmus Lerdorf wrote:
> Ok, so as promised I ran some of the options we have that came up last
> week by Douglas Crockford.
>
> 1. Document the fact that if you want to strictly conform to the JSON
> spec and be sure your json_encode output will work in various J
Settings which change behaviour like that aren't really all that fun
for third party/portable applications developers, e.g. forum software
and the likes. magic_quotes_gpc and others are good examples of this.
Going back to Rasmus' mail based on his discussion with Douglas, I
think that option #1 (
On Tue, Dec 16, 2008 at 3:06 PM, Richard Quadling
wrote:
> Would it be at all possible to have an ini setting json.strict_encode = On
>
> So, my code doesn't change, but I can activate it globally.
> Essentially I don't want to shoot myself. I don't want to take the
> safety off.
I think we have
2008/12/16 Scott MacVicar :
> Richard Quadling wrote:
>> 2008/12/15 mike :
>>> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf wrote:
>>>
1. Document the fact that if you want to strictly conform to the JSON
spec and be sure your json_encode output will work in various JSON
pars
On 12/16/2008 14:23, Alexey Zakhlestin wrote:
On Tue, Dec 16, 2008 at 3:20 PM, troels knak-nielsen wrote:
On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar wrote:
For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can use
json_encode($var,
On Tue, Dec 16, 2008 at 3:20 PM, troels knak-nielsen wrote:
> On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar wrote:
>> For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
>> parameter to the options flag. So you can use
>>
>> json_encode($var, JSON_STRICT_ENCODE);
>>
>
> I'm really
troels knak-nielsen wrote:
> On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar wrote:
>> For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
>> parameter to the options flag. So you can use
>>
>> json_encode($var, JSON_STRICT_ENCODE);
>>
>
> I'm really not a fan of named constants to
On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar wrote:
> For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
> parameter to the options flag. So you can use
>
> json_encode($var, JSON_STRICT_ENCODE);
>
I'm really not a fan of named constants to change the semantics of a
function lik
Richard Quadling wrote:
> 2008/12/15 mike :
>> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf wrote:
>>
>>> 1. Document the fact that if you want to strictly conform to the JSON
>>> spec and be sure your json_encode output will work in various JSON
>>> parsers, you have to pass it a PHP array
2008/12/15 mike :
> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf wrote:
>
>> 1. Document the fact that if you want to strictly conform to the JSON
>> spec and be sure your json_encode output will work in various JSON
>> parsers, you have to pass it a PHP array or object.
>
> Instead of json
Hi Rasmus,
Am Montag, den 15.12.2008, 14:17 -0800 schrieb Rasmus Lerdorf:
[...]
> There has to be a way to do a basic type without any sort of error or
> warning. E_STRICT, even if turned off, is slow. It ends up calling
> php_verror to construct the entire error string before it checks and
> se
Hi,
JSON allows extensions. I can not understand why this is not an extension
that makes sense:
json_encode($var, $allowScalar = false);
In PHP outputting of JS literals is a common action, so all you'll achieve
by completely removing this option, is forcing people to go from this:
echo '
On Mon, Dec 15, 2008 at 8:58 PM, Mark Karpeles wrote:
> I believe part of the job should be the programmer's job too.
I'm a programmer. I expect json_* functions to encode and decode to
JSON specifications. Not PHP's original interpretation of it...
> Lazy mode is "not that good", as it's going
Hi,
I believe part of the job should be the programmer's job too.
json_encode() is way too useful to pass things to javascript (the other
way around is not that easy, but I have a function called "JSparse"
which work nicely with .toSource() output, and an implementation
of .toSource() for MSIE, I
On Mon, Dec 15, 2008 at 1:43 PM, John Carter -X (johncart - PolicyApp
Ltd at Cisco) wrote:
> How about a strict mode added to the list of the current json_encode()
> options?
>
> That way current code will continue to work and anyone reading the docs
> will know the default behaviour isn't strictl
Edward Z. Yang wrote:
> Jared Williams wrote:
>> Don't think that's what he said... More like...
>>
>> assert(is_object($foo) || is_array($foo)); // ensure strictly conforming
>> $json = json_encode($foo);
>
> Which is, for all intents and purposes, the same thing. (Since you can't
> pass json_enc
How about a strict mode added to the list of the current json_encode()
options?
That way current code will continue to work and anyone reading the docs
will know the default behaviour isn't strictly correct.
John.
John Carter
Development Manager
NAC Governance Server
Cisco
johnc...@cisco.com
+44
On Mon, Dec 15, 2008 at 1:10 PM, troels knak-nielsen wrote:
> I, for one, think that the only sane choices are 1 or 2. The third
> option is way too magic, and will end up confusing people.
In that case I would have to go for #2.
Personally I want to see PHP be as standards-compliant and compat
On Mon, Dec 15, 2008 at 10:02 PM, mike wrote:
> I'd like to see it "do the right thing" in PHP 6, and perhaps if
I think everybody agrees to that. The question at hand, is what the
right thing is.
I, for one, think that the only sane choices are 1 or 2. The third
option is way too magic, and wil
On Mon, Dec 15, 2008 at 12:55 PM, Uwe Schindler wrote:
> As is noted in an earlier mail, I would prefer 1 (simply document it in the
> function description). In my opinion, if somebody then passes a basic type
> to json_encode he is aware of what he is doing (hopefully).
>
> For compatibility with
As is noted in an earlier mail, I would prefer 1 (simply document it in the
function description). In my opinion, if somebody then passes a basic type
to json_encode he is aware of what he is doing (hopefully).
For compatibility with current code and securely escaping strings for
javascript it is
Jared Williams wrote:
> Don't think that's what he said... More like...
>
> assert(is_object($foo) || is_array($foo)); // ensure strictly conforming
> $json = json_encode($foo);
Which is, for all intents and purposes, the same thing. (Since you can't
pass json_encode(34) for strict JSON).
PHP ha
> -Original Message-
> From: mike [mailto:mike...@gmail.com]
> Sent: 15 December 2008 18:10
> To: Rasmus Lerdorf
> Cc: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] json_encode()
>
> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf
> wrote:
>
&g
On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf wrote:
> 1. Document the fact that if you want to strictly conform to the JSON
> spec and be sure your json_encode output will work in various JSON
> parsers, you have to pass it a PHP array or object.
Instead of json_encode(34) the suggestion
Hi,
So I guess the conclusion is:
Create a feature request ticket, take the information from this thread
and put it into the ticket .. and ideally write a patch yourself or
motivate someone else ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
Hi Jaris:
> I don't know if I'm using json_encode for something it's not supposed to
> do. I'm using it to serialize an object to send it to another
> runtime-environment in response to an remote call, just like what I can
> do with SOAP, REST or RMI. In this context I don't see much sense i
2008/10/9 Rodrigo Saboya <[EMAIL PROTECTED]>:
> Jarismar Chaves da Silva wrote:
>>
>> I agree with you.
>> But when using json_encode I believe the developer wants to transfer the
>> complete object state, just like when using serialize.
>> Serialize does see private/protected class members, while
2008/10/10 Jarismar Chaves da Silva <[EMAIL PROTECTED]>:
>
>
> Rodrigo Saboya wrote:
>>
>> Jarismar Chaves da Silva wrote:
>>>
>>> I agree with you.
>>> But when using json_encode I believe the developer wants to transfer the
>>> complete object state, just like when using serialize.
>>> Serialize
Rodrigo Saboya wrote:
Jarismar Chaves da Silva wrote:
I agree with you.
But when using json_encode I believe the developer wants to transfer
the complete object state, just like when using serialize.
Serialize does see private/protected class members, while json_encode
not.
Javascript does n
Jarismar Chaves da Silva wrote:
I agree with you.
But when using json_encode I believe the developer wants to transfer the
complete object state, just like when using serialize.
Serialize does see private/protected class members, while json_encode not.
Javascript does not have class-accessors s
Yes, it like it too. Just like an OOP should be.
Dave Ingram wrote:
however changing this at this point would be a huge security issue, so
if at all, it would need to be handled by an optional parameter that
defaults to false.
That would be unclean. If it's implemented in some way, j
1 - 100 of 123 matches
Mail list logo
