> On Jan 20, 2021, at 09:43, Dik Takken <dik.tak...@gmail.com> 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 doesn't, but otherwise . >> Changing to a different name entirely would solve that, such as var_repr(), >> var_representation(), serialize_[value_]as_php_snippet(), etc. >> > > I am considering to try and introduce a __repr() magic method that is > similar to the __repr__() method from Python. Having a var_repr() method > which does not use the __repr() method would be confusing. So I would > like to suggest not to use that name. > > As the intent of the resulting string is to obtain PHP code that will > construct the variable, another option might be: var_constructor(). > > Regards, > Dik Takken
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 coding standards within the community tend to lean more toward verbosity than terseness, when it comes to naming things. Perhaps we should follow the lead of `__toString()` and use `__toRepresentation()`? Maybe also introduce a `Representable` interface, like `Stringable`? https://wiki.php.net/rfc/stringable Cheers, Ben
signature.asc
Description: Message signed with OpenPGP
