Hi internals,
> > As the intent of the resulting string is to obtain PHP code that will
construct the variable, another option might be: var_constructor().
>
> Wouldn't this be extremely confusing given that we use the name constructor
> for OOP?
I'd agree, var_constructor($x) could be mistake
Hi Sara Golemon and Rowan Tommins,
> > On 20/01/2021 20:21, Claude Pache wrote:
> > > Or `short_var_export()` could just reuse the existing `__debugInfo()`
> > > magic method (which is already used by both `var_dump()` and
> > > `print_r`, but not by `var_export()`). The programmer would just need
Hi Sara Golemon,
> * You should drop the $return parameter and make it always return. As this
is primarily an export and not a dumping function, printing to stdout
doesn't make sense to me.
>
> I'd argue the opposite. If dumping a particularly large tree of elements,
> serializing that to a sing
On Wed, Jan 20, 2021 at 3:44 PM Rowan Tommins
wrote:
> On 20/01/2021 20:21, Claude Pache wrote:
> > Or `short_var_export()` could just reuse the existing `__debugInfo()`
> > magic method (which is already used by both `var_dump()` and
> > `print_r`, but not by `var_export()`). The programmer woul
Hi Internals,
Following my earlier announcement in https://wiki.php.net/rfc/improve_mysqli
I decided to submit a dedicated RFC for the first proposal.
This RFC proposes to change the default mysqli error reporting mode to
exception mode. This change follows the same change in PDO. The RFC can be
On 20/01/2021 20:21, Claude Pache wrote:
Or `short_var_export()` could just reuse the existing `__debugInfo()`
magic method (which is already used by both `var_dump()` and
`print_r`, but not by `var_export()`). The programmer would just need
to make sure that `__set_state()` can consume the arr
> Le 20 janv. 2021 à 19:50, Rowan Tommins a écrit :
>
> Should we be aiming for a single function that can take over from some or all
> of the others, and deprecate them, rather than just adding to the confusion?
Or `short_var_export()` could just reuse the existing `__debugInfo()` magic
met
On Tue, Jan 19, 2021 at 3:59 AM Nikita Popov wrote:
> * You should drop the $return parameter and make it always return. As this
> is primarily an export and not a dumping function, printing to stdout
> doesn't make sense to me.
>
I'd argue the opposite. If dumping a particularly large tree of
On 18/01/2021 21:12, tyson andre wrote:
Thoughts?
(e.g. for the name, short_var_export() seemed more appropriate than
var_export_short(), pretty_var_export() or canonical_var_export())
While I agree that all the suggestions in this thread would improve
var_export, I worry that it is failing
> On Jan 20, 2021, at 10:28, Marco Pivetta wrote:
>
> On Wed, Jan 20, 2021 at 5:27 PM Ben Ramsey wrote:
>> Taking this to a new thread so I don’t derail the `short_var_export()`
>> thread.
>>
>> Dik, I like this addition, but I think the name “repr” might be confusing to
>> PHP developers who
On Wed, Jan 20, 2021 at 5:27 PM Ben Ramsey wrote:
> Taking this to a new thread so I don’t derail the `short_var_export()`
> thread.
>
> Dik, I like this addition, but I think the name “repr” might be confusing
> to PHP developers who aren’t familiar with Python idioms. PHP function
> names and c
> On Jan 20, 2021, at 09:43, Dik Takken wrote:
>
> On 19-01-2021 16:12, tyson andre wrote:
>> It seems inconsistent and prone to bugs when refactoring (e.g. converting to
>> string and not using the result)
>> to have two functions named var_export where one prints by default and the
>> other d
>
> I am considering to try and introduce a __repr() magic method that is
> similar to the __repr__() method from Python.
No more magic methods, please. We have too many already.
As the intent of the resulting string is to obtain PHP code that will
>
construct the variable, another option might
> On Jan 19, 2021, at 18:55, tyson andre wrote:
>
> Hi internals,
>
> Voting has started on
> https://wiki.php.net/rfc/readline_interactive_shell_result_function
> on 2021-01-19, and ends on 2021-02-02.
>
> This RFC proposes to dump the results of non-null expressions using
> var_dump/var_exp
On 19-01-2021 16:12, tyson andre wrote:
> It seems inconsistent and prone to bugs when refactoring (e.g. converting to
> string and not using the result)
> to have two functions named var_export where one prints by default and the
> other doesn't, but otherwise .
> Changing to a different name en
On Tue, Dec 1, 2020 at 3:57 PM Nikita Popov wrote:
> Hi internals,
>
> I've put up an RFC to make the handling of "null" arguments consistent
> between internal and user-defined functions:
>
> https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
>
> I started an informal discussion for
On Thu, Jan 7, 2021 at 12:30 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to propose that string keys be allowed when unpacking into
> arrays: https://wiki.php.net/rfc/array_unpacking_string_keys
>
> Especially as unpacking in calls supports string keys now, I believe it is
> time to drop
17 matches
Mail list logo
