On 25/01/2021 14:40, tyson andre wrote:
I'm concerned PHP may indefinitely keep the default behavior of `array (`,
`NULL`, etc. in var_export.
I agree that that's likely, but I don't find it concerning, unless
"array()" is deprecated or "null" becomes case sensitive.
You have proposed no
Hi Rowan,
> > If a php developer is learning the language through php's official manual,
> > official language reference, or through an online tutorial,
> > that would have sections showing the different scalar types, examples
> > involving objects and/or arrays, etc.
> > Those use var_export/va
Hi Dusk,
> There's an interesting edge case where this does become useful. If an
> evaluable representation of a data structure is written to a file (wrapped
> with ` can be stored in opcache. This is dramatically faster than unserialize() or
> json_decode(), especially for large structures.
>
On Jan 24, 2021, at 05:42, Rowan Tommins wrote:
> As far as I know I have never had any reason to generate code and then eval()
> it, and can't think of a situation where I ever would. If I wanted a
> machine-readable output from a variable, I would use serialize() or
> json_encode().
>
> That
On 24/01/2021 19:38, tyson andre wrote:
If a php developer is learning the language through php's official manual,
official language reference, or through an online tutorial,
that would have sections showing the different scalar types, examples involving
objects and/or arrays, etc.
Those use va
Hi Rowan Tommins,
> > **php-src phpt tests are for tests of php itself, which puts strict and
> > atypical limitations on the test framework.**
> > php-src's phpt test framework may represent needs of php-src and some pecl
> > maintainers, not userland.
>
> I'm not sure what point you're trying
On 24/01/2021 16:17, tyson andre wrote:
Even if a developer such as yourself doesn't need to generate code and don't
expect to directly use it,
**some of the applications and libraries they do use everyday would need to
generate human and machine readable code.**
Sure, I believe you that the
Hi Rowan Tommins,
> > var_representation may be useful to a user when any of the following apply:
> >
> > - You are generating a snippet of code to eval() in a situation where the
> > snippet will occasionally or frequently be read by a human (If the output
> > never needs to be read by a huma
On 23/01/2021 21:07, tyson andre wrote:
I've added those to
https://wiki.php.net/rfc/readable_var_representation#when_would_a_user_use_var_representation
, including when I think the VAR_REPRESENTATION_SINGLE_LINE flag would be
useful to users.
Thanks, it's good to at least know your opinion
Hi Rowan Tommins,
> > Hi internals,
> >
> > I've created https://wiki.php.net/rfc/readable_var_representation based on
> > my original proposal in https://externals.io/message/112924
> >
> > This RFC proposes adding a new function `var_representation(mixed $value,
> > int $flags=0): string`
>
> M
On 23/01/2021 00:50, tyson andre wrote:
Hi internals,
I've created https://wiki.php.net/rfc/readable_var_representation based on
my original proposal in https://externals.io/message/112924
This RFC proposes adding a new function `var_representation(mixed $value, int
$flags=0): string`
My he
Hi internals,
I've created https://wiki.php.net/rfc/readable_var_representation based on
my original proposal in https://externals.io/message/112924
This RFC proposes adding a new function `var_representation(mixed $value, int
$flags=0): string`
with the following differences from var_export:
1
12 matches
Mail list logo
