Re: [PHP-DEV] Suggested change: change priority of new and ->
> > Is that creating an instance of the class name stored in the 0th index of > the array $var or is it creating an instance of the class name stored in > $var and accessing the 0th index using ArrayAccess? > As soon as $var gets involved, it should be prioritized above the new operator. So it's equivalent of "new ($var[0])" Jaroslav
Re: [PHP-DEV] Suggested change: change priority of new and ->
On 8 February 2018 18:38:36 GMT+00:00, Mcmuffin Mcguffin wrote: >Hi, > >It's a common idiom in object-oriented languages to create an object >and >then immediately call a method on it, such as (in C# or Java): > >new DateTime ().ToString () > >However, PHP grammar does not work this way. This would definitely be nice to have, and thanks for looking into what the necessary change would look like. I think the next challenge is to work out the different ways a dynamic class construction could happen, and which ones: a) will be unaffected by the change b) are an error now and will be allowed after c) are allowed now and will be an error after d) will work in both versions but change behaviour It's anything that falls into category (d) that is particularly problematic, as it means users will see odd bugs of they don't know about the change. The clearer we can make these examples, the better. Contrary to other responses, I think this would definitely need to happen in a major version, as it is quite clearly a breaking change. There's not much that can be done to deprecate code relying on the current rules, but we can publicise how to make code that is compatible before and after. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] var_export() array format
I sometimes use var_export() to export a structured array and then
copy+paste it into my code.
And sometimes I use it as part of an automatic code generator.
Unfortunately, the output is usually not in the format that I want, or
that is common for most projects / code styles.
- Indentation is 2 spaces instead of 4, as in most projects.
- It uses traditional "array()" format, instead of "[]".
- It puts a space after "array", so "array (" instead of "array(".
- It puts "array (" on a new line after "=>", instead of "'key' =>
array(" on one line.
- Empty arrays occupy two lines instead of one, so "array (\n)"
instead of "array ()".
E.g. https://3v4l.org/nl4uJ
The IDE can fix some of these problems with a single operation. Others
require cumbersome manual treatment.
E.g. my IDE (PhpStorm) cannot automatically remove the line break
between "=>" and "array (".
Code generators can be designed to fix all of the problems, but imo
they should not have to deal with this stuff.
--
## Proposed change
I really think the default behavior of var_export() must remain
unchanged for BC.
Re-running the same script in different PHP versions should produce
the same output each time.
What we can do is add a third parameter with flags.
Then we can introduce named flag combinations for known code styles.
Flag constants could be
- VAR_EXPORT_INDENT_TAB
- VAR_EXPORT_INDENT_2
- VAR_EXPORT_INDENT_3
- VAR_EXPORT_INDENT_4
- VAR_EXPORT_ARRAY_SHORT_SYNTAX for "[]" instead of "array (..)".
- VAR_EXPORT_ARRAY_NO_INITIAL_BREAK for " => array (" instead of "
=>\n array(".
- VAR_EXPORT_ARRAY_NO_INITIAL_SPACE for "array(" instead of "array (".
- VAR_EXPORT_ARRAY_ONELINE_IF_EMPTY
>From other discussions:
- VAR_EXPORT_STDCLASS_AS_CAST for "(object)array (.." instead of
"stdClass::__set_state(array(..))".
- VAR_EXPORT_FQCN for "\stdClass" and "\Acme\Animal" instead of
"stdClass" and "Acme\Animal".
The naming is open for debate, of course.
I prefixed all array-related constants with *_ARRAY_* so that they
group up more nicely.
I considered for a moment to prefix the constants with "PHP_" or
something else instead of "VAR_EXPORT_", so they could be used
elsewhere in the future.
--
For a short time I considered to mix all this into the second
parameter which currently only accepts boolean.
Once you use any non-zero flags, it would always return.
For my taste, the print-by-default is a bad idea anyway.
But I now think a third parameter would be more transparent and clean.
The indentation could be solved with a 4th parameter instead of
*_INDENT_* constants.
See https://externals.io/message/51345#51351
Another alternative would be to introduce yet another function which
always returns, has a more useful default format, and where the second
parameter accepts flags like mentioned above.
But somehow it feels wrong to me to introduce such a new function
which mostly does the same as an already existing one.
But most of them are quite specific to var_export(), and would not
make sense elsewhere.
--
Why not a userland implementation?
E.g. https://packagist.org/packages/riimu/kit-phpencoder
var_export() is often used in experimental code or when just playing
around, situations where developers usually prefer to avoid adding a
3rd party dependency.
Also there is no way to add a 3rd party dependency on e.g. 3v4l.org.
And a custom one-off implementation is not what developers should
spend their time on (although I did it a few times already).
-
-- Andreas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] var_export() array format
I just think that is not responsability of PHP to care about output format
at core level (although we have the json pretty output support...).
Maybe you can found some solution with packages.
Em 17 de fev de 2018 10:28 PM, "Andreas Hennings"
escreveu:
> I sometimes use var_export() to export a structured array and then
> copy+paste it into my code.
> And sometimes I use it as part of an automatic code generator.
>
> Unfortunately, the output is usually not in the format that I want, or
> that is common for most projects / code styles.
>
> - Indentation is 2 spaces instead of 4, as in most projects.
> - It uses traditional "array()" format, instead of "[]".
> - It puts a space after "array", so "array (" instead of "array(".
> - It puts "array (" on a new line after "=>", instead of "'key' =>
> array(" on one line.
> - Empty arrays occupy two lines instead of one, so "array (\n)"
> instead of "array ()".
>
> E.g. https://3v4l.org/nl4uJ
>
> The IDE can fix some of these problems with a single operation. Others
> require cumbersome manual treatment.
> E.g. my IDE (PhpStorm) cannot automatically remove the line break
> between "=>" and "array (".
>
> Code generators can be designed to fix all of the problems, but imo
> they should not have to deal with this stuff.
>
> --
>
> ## Proposed change
>
> I really think the default behavior of var_export() must remain
> unchanged for BC.
> Re-running the same script in different PHP versions should produce
> the same output each time.
>
> What we can do is add a third parameter with flags.
> Then we can introduce named flag combinations for known code styles.
>
> Flag constants could be
> - VAR_EXPORT_INDENT_TAB
> - VAR_EXPORT_INDENT_2
> - VAR_EXPORT_INDENT_3
> - VAR_EXPORT_INDENT_4
> - VAR_EXPORT_ARRAY_SHORT_SYNTAX for "[]" instead of "array (..)".
> - VAR_EXPORT_ARRAY_NO_INITIAL_BREAK for " => array (" instead of "
> =>\n array(".
> - VAR_EXPORT_ARRAY_NO_INITIAL_SPACE for "array(" instead of "array (".
> - VAR_EXPORT_ARRAY_ONELINE_IF_EMPTY
>
> From other discussions:
> - VAR_EXPORT_STDCLASS_AS_CAST for "(object)array (.." instead of
> "stdClass::__set_state(array(..))".
> - VAR_EXPORT_FQCN for "\stdClass" and "\Acme\Animal" instead of
> "stdClass" and "Acme\Animal".
>
> The naming is open for debate, of course.
>
> I prefixed all array-related constants with *_ARRAY_* so that they
> group up more nicely.
>
> I considered for a moment to prefix the constants with "PHP_" or
> something else instead of "VAR_EXPORT_", so they could be used
> elsewhere in the future.
>
> --
>
> For a short time I considered to mix all this into the second
> parameter which currently only accepts boolean.
> Once you use any non-zero flags, it would always return.
> For my taste, the print-by-default is a bad idea anyway.
>
> But I now think a third parameter would be more transparent and clean.
>
> The indentation could be solved with a 4th parameter instead of
> *_INDENT_* constants.
> See https://externals.io/message/51345#51351
>
> Another alternative would be to introduce yet another function which
> always returns, has a more useful default format, and where the second
> parameter accepts flags like mentioned above.
> But somehow it feels wrong to me to introduce such a new function
> which mostly does the same as an already existing one.
> But most of them are quite specific to var_export(), and would not
> make sense elsewhere.
>
> --
>
> Why not a userland implementation?
> E.g. https://packagist.org/packages/riimu/kit-phpencoder
>
> var_export() is often used in experimental code or when just playing
> around, situations where developers usually prefer to avoid adding a
> 3rd party dependency.
> Also there is no way to add a 3rd party dependency on e.g. 3v4l.org.
> And a custom one-off implementation is not what developers should
> spend their time on (although I did it a few times already).
>
> -
>
> -- Andreas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] var_export() array format
On 18 February 2018 at 02:04, David Rodrigues wrote: > I just think that is not responsability of PHP to care about output format > at core level (although we have the json pretty output support...). Why not? E.g. JSON_PRETTY_PRINT is something I use a lot, often in situations where I don't or cannot use a 3rd party package. E.g. - if I abuse 3v4l.org as a php console - in a one-off single-file cli script - in a debugging session, or any temporary code. - if my involvement with the project is not deep enough to justify adding a dependency > > Maybe you can found some solution with packages. See the last section of my initial message: >> >> Why not a userland implementation? >> E.g. https://packagist.org/packages/riimu/kit-phpencoder >> >> var_export() is often used in experimental code or when just playing >> around, situations where developers usually prefer to avoid adding a >> 3rd party dependency. >> Also there is no way to add a 3rd party dependency on e.g. 3v4l.org. >> And a custom one-off implementation is not what developers should >> spend their time on (although I did it a few times already). If we already have a native function that generates PHP code, then we should expect it to produce usable output.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] var_export() array format
> On Feb 17, 2018, at 18:27, Andreas Hennings wrote: > > What we can do is add a third parameter with flags. Big +1. When writing tests and setting the $expected value, one of the constantly recurring drudgeries is reformatting the correct var_export($actual) output from arrays to match the surrounding code style. This would reduce that tedium by an order of magnitude. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
