[PHP-DEV] PHP 7.2 minimum ICU version

[Trevor Rowbotham]

Hello,

I realize that this may be a little late given that PHP 7.2 initially released
roughly 2 years ago, but I came across an issue yesterday regarding the minimum
required version of the ICU library. The user's hosting provider was using
PHP 7.2.1, but it was linked with an ICU version of 4.2.1 (over 10 years old!).

According to the 
https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003
RFC, the INTL_IDNA_VARIANT_2003 constant was deprecated in PHP 7.2. However, 
this
RFC did not increase the minimum required version of ICU, which is currently
4.0 according to https://www.php.net/manual/en/intl.requirements.php. This
leaves an opening where PHP 7.2 can be built with an ICU version less than 4.6,
but the user cannot avoid the deprecation notice because the replacement,
INTL_IDNA_VARIANT_UTS46, wasn't added until ICU 4.6.

Is there any way to increase the minimum required ICU version in PHP 7.2 and 
7.3 to
at least 4.6, which would ensure that the upgrade path is actually available to 
users
trying to avoid the deprecation notice?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Windows builds of PHP 7.4+ use Visual Studio 2019

[Christoph M. Becker]

Hi all!

On 06.06.2019 at 14:11, Christoph M. Becker wrote:

> I like to inform you, that the official Windows builds of PHP 7.4 and
> master (available from windows.php.net; currently only snapshot builds,
> of course) are done with Visual Studio 2019.  While it is still possible
> to build these PHP versions with Visual Studio 2017, this is no longer
> tested.
>
> This also means a small but important change, namely that we are no
> longer using the "vc" prefix (e.g. "vc14", "vc15") to refer to *new*
> Visual Studio versions, but rather "vs" (i.e. "vs16").  The detailed
> reasoning is explained in the post titled "Visual Studio 2019
> Builds"[1].  Recent beta versions of the PHP SDK are supposed to fully
> support this naming change already (and particularly the renaming of the
> PHP_SDK_VC environment variable to PHP_SDK_VS).  You may have to adapt
> custom tooling accordingly, though.

I like to inform you, that the PHP for Windows team has decided to
switch back to Visual Studio 2017 for PHP 7.4.  For the reasoning and
further details see .

Thanks,
Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: var_export - short syntax for array

[Benjamin Morel]

>
> There are other issues with the format besides just the long array syntax.
> E.g. opening bracket on same line? Indentation?


For the record, I have a userland implementation of var_export() that does
all of this:

- (object) array export of stdClass for PHP < 7.3
- short array syntax
- bracket on the same line
- array of scalars on a single line (optional)
- export classes without __set_state()
- export closures

https://github.com/brick/varexporter

I'm currently working on supporting object identity and circular references.
Feedback welcome!

— Benjamin

Re: [PHP-DEV] RFC: var_export - short syntax for array

[Lynn]

On Wed, Aug 21, 2019 at 10:25 AM Andreas Hennings 
wrote:

> Avoiding disruption is indeed a concern.
> As an example, Drupal 7 features module uses a custom variation of
> var_export() to write configuration to code, which is then typically
> tracked in git.
>

Hi Andreas,

If the output is being tracked in git, it could follow the same rules as
all other code by using a code formatting fixer such as phpcbf. I don't
think the responsibility here is the output format of var_export, as it's
the developer having control over what's being committed to git. I don't
see this as an issue that PHP should solve.

Regards,
Lynn van der Berg

Re: [PHP-DEV] RFC: var_export - short syntax for array

[Andreas Hennings]

Avoiding disruption is indeed a concern.
As an example, Drupal 7 features module uses a custom variation of
var_export() to write configuration to code, which is then typically
tracked in git.

I am not sure if changing the native var_export() would have an impact
here, and anyway the module can be updated if necessary, to guarantee
stability of the output.

What I would ask is to limit the frequency of change in this function, or
make it opt-in.

There are other issues with the format besides just the long array syntax.
E.g. opening bracket on same line? Indentation?
https://3v4l.org/MFLgd

Ideally all of this would be "normalized" in one go, based on popular
convention (psr-whichever), or it should be opt-in.

Alternatively there could be a new function or class, leaving var_export()
alone.

Влад Макин  schrieb am Mi., 21. Aug. 2019, 08:55:

> Thanks for the feedback!  I will back with improved version of RFC.
>
> вт, 20 авг. 2019 г., 23:01 Sara Golemon :
>
> > On Tue, Aug 20, 2019 at 1:05 PM Влад Макин  wrote:
> >
> >> I would like to propose a little change in var_export function behavior.
> >> For today, this function returns string representation of array in old
> >> style with “array” keyword:
> >>
> >> var_export([]); // array()
> >>
> >> I think it would be better if the function returned array representation
> >> in
> >> modern square brackets syntax:
> >>
> >> var_export([]); // []
> >>
> >> I do like the idea of doing this, and would even be generally okay with
> > just making always work that way since the introduction of square bracket
> > syntax is really *quite* old.
> >
> > The only people I could see being bothered by the change in output would
> > be automated code-generation suddenly seeing a (potentially quite
> massive)
> > diff as the bracket style changes.  As an example,
> > https://github.com/php/web-php/blob/master/include/releases.inc is a 10k
> > line var_export() generated list.  I'm actually /not/ bothered by the
> idea
> > of having a big point-in-time flip of that structure, though I'd want to
> > make sure all RMs switch versions at the same time, otherwise it could
> get
> > noisy.
> >
> > Perhaps an option to quell any dissent might be to add a third param
> > $options to allow controlling this behavior.
> >
> > function var_export(mixed $data, bool $return = false, int $options = 0):
> > string {}
> >
> > And you could either pass EXPORT_SHORT_ARRAY or EXPORT_LONG_ARRAY or
> > whatever you want to call the constants depending on which behavior you'd
> > make default (and honestly, I think we'd make the existing format
> default).
> >
> > -Sara
> >
>

Re: [PHP-DEV] RFC: var_export - short syntax for array

[Влад Макин]

Thanks for the feedback!  I will back with improved version of RFC.

вт, 20 авг. 2019 г., 23:01 Sara Golemon :

> On Tue, Aug 20, 2019 at 1:05 PM Влад Макин  wrote:
>
>> I would like to propose a little change in var_export function behavior.
>> For today, this function returns string representation of array in old
>> style with “array” keyword:
>>
>> var_export([]); // array()
>>
>> I think it would be better if the function returned array representation
>> in
>> modern square brackets syntax:
>>
>> var_export([]); // []
>>
>> I do like the idea of doing this, and would even be generally okay with
> just making always work that way since the introduction of square bracket
> syntax is really *quite* old.
>
> The only people I could see being bothered by the change in output would
> be automated code-generation suddenly seeing a (potentially quite massive)
> diff as the bracket style changes.  As an example,
> https://github.com/php/web-php/blob/master/include/releases.inc is a 10k
> line var_export() generated list.  I'm actually /not/ bothered by the idea
> of having a big point-in-time flip of that structure, though I'd want to
> make sure all RMs switch versions at the same time, otherwise it could get
> noisy.
>
> Perhaps an option to quell any dissent might be to add a third param
> $options to allow controlling this behavior.
>
> function var_export(mixed $data, bool $return = false, int $options = 0):
> string {}
>
> And you could either pass EXPORT_SHORT_ARRAY or EXPORT_LONG_ARRAY or
> whatever you want to call the constants depending on which behavior you'd
> make default (and honestly, I think we'd make the existing format default).
>
> -Sara
>