Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties

[Brady Wetherington via internals]

On Wed, Dec 1, 2021 at 9:16 PM Sara Golemon  wrote:
>
> On Tue, Nov 30, 2021 at 10:18 PM Brady Wetherington 
>  wrote:
>>
>> >>> …It's been merged to master, so you could stand up a build now and point 
>> >>> to the many deprecation warnings you're expecting.  I'm not saying send 
>> >>> PRs to fix them all, just show real impact rather than theoretical 
>> >>> guessing. …
> ...
> Does it look like there's any sensitive information in these log entries?  
> You mentioned they were only in external dependencies so I'm thinking/hoping 
> not.  What I'm getting at is: Would you mind sharing those raw logs 
> somewhere. I'm sure someone will find it a fun opportunity to make some pull 
> requests in a variety of projects.

Nope, not at all. Here I extracted out just the specific deprecations
and added counts so anyone can see how many times a deprecation
warning came up. Please do note that it is very likely that newer
versions of these libraries may have already resolved the issues, I
haven't bothered yet to try and upgrade to the latest versions.




uberbrady@GrokBook-Pro-Black snipe-it % cut -d " " -f 4-
storage/logs/deprecations.log|sort |uniq -c
  10 Creation of dynamic property
Barryvdh\Debugbar\DataCollector\ViewCollector::$name is deprecated in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/barryvdh/laravel-debugbar/src/DataCollector/ViewCollector.php
on line 24
  10 Creation of dynamic property
Barryvdh\Debugbar\DataFormatter\QueryFormatter::$cloner is deprecated
in 
/Users/uberbrady/Documents/grokability/snipe-it/vendor/maximebf/debugbar/src/DebugBar/DataFormatter/DataFormatter.php
on line 23
  10 Creation of dynamic property
Barryvdh\Debugbar\DataFormatter\QueryFormatter::$dumper is deprecated
in 
/Users/uberbrady/Documents/grokability/snipe-it/vendor/maximebf/debugbar/src/DebugBar/DataFormatter/DataFormatter.php
on line 24
  30 Creation of dynamic property
Barryvdh\Debugbar\DataFormatter\SimpleFormatter::$cloner is deprecated
in 
/Users/uberbrady/Documents/grokability/snipe-it/vendor/maximebf/debugbar/src/DebugBar/DataFormatter/DataFormatter.php
on line 23
  30 Creation of dynamic property
Barryvdh\Debugbar\DataFormatter\SimpleFormatter::$dumper is deprecated
in 
/Users/uberbrady/Documents/grokability/snipe-it/vendor/maximebf/debugbar/src/DebugBar/DataFormatter/DataFormatter.php
on line 24
  10 Creation of dynamic property
DebugBar\DataFormatter\DataFormatter::$cloner is deprecated in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/maximebf/debugbar/src/DebugBar/DataFormatter/DataFormatter.php
on line 23
  10 Creation of dynamic property
DebugBar\DataFormatter\DataFormatter::$dumper is deprecated in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/maximebf/debugbar/src/DebugBar/DataFormatter/DataFormatter.php
on line 24
  12 Creation of dynamic property
Illuminate\Database\MySqlConnection::$readWriteType is deprecated in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/laravel/framework/src/Illuminate/Database/Connection.php
on line 1368
   4 class_exists(): Passing null to parameter #1 ($class) of type
string is deprecated in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/adldap2/adldap2/src/Configuration/DomainConfiguration.php
on line 153
 626 mb_convert_encoding(): Handling HTML entities via mbstring is
deprecated; use htmlspecialchars, htmlentities, or
mb_encode_numericentity/mb_decode_numericentity instead in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/symfony/var-dumper/Dumper/HtmlDumper.php
on line 963
  84 preg_match(): Passing null to parameter #2 ($subject) of type
string is deprecated in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/barryvdh/laravel-debugbar/src/JavascriptRenderer.php
on line 150
   4 str_replace(): Passing null to parameter #3 ($subject) of type
array|string is deprecated in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/laravel/passport/src/PassportServiceProvider.php
on line 268
  84 substr(): Passing null to parameter #1 ($string) of type string
is deprecated in
/Users/uberbrady/Documents/grokability/snipe-it/vendor/barryvdh/laravel-debugbar/src/JavascriptRenderer.php
on line 150

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

Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties

[Sara Golemon]

On Tue, Nov 30, 2021 at 10:18 PM Brady Wetherington <
bwethering...@grokability.com> wrote:

> >>> …It's been merged to master, so you could stand up a build now and
> point to the many deprecation warnings you're expecting.  I'm not saying
> send PRs to fix them all, just show real impact rather than theoretical
> guessing. …
> Okay - good news/bad news/good news -
>
> Bad News: That's because later versions of Laravel dump all
> deprecation warnings straight to /dev/null by default. If you
> configure a log 'channel' for 'deprecations', *then* you get actual
> results. One page load (our dashboard page) generated 267KB of
> deprecation warnings. Clicking through most of the main pages of our
> app generated around 3.5MB of them. And these aren't full
> stack-traces, they're just messages like:
>
> "[2021-12-01 03:48:23] local.WARNING: Creation of dynamic property
> Illuminate\Database\MySqlConnection::$readWriteType is deprecated in
>
> /Users/uberbrady/Documents/grokability/snipe-it/vendor/laravel/framework/src/Illuminate/Database/Connection.php
> on line 1368"
>
> Good News: *Many many many* of those deprecation warnings were repeats
> of the same deprecated thing from the exact same place. And *very very
> few* were from the dynamic properties thing. *None* of the dynamic
> properties deprecations were from our code. Everything was from
> composer dependencies, and only a small handful - so, probably pretty
> easy to remediate when it comes to that.
>
>
Does it look like there's any sensitive information in these log entries?
You mentioned they were only in external dependencies so I'm
thinking/hoping not.  What I'm getting at is: Would you mind sharing those
raw logs somewhere. I'm sure someone will find it a fun opportunity to make
some pull requests in a variety of projects.

-Sara

Re: [PHP-DEV] Re: Array comparison works completely different than documented?

[Benjamin Morel]

>
> The point is that $a > $b is actually checking whether $b <= $a.  This
> is fine for ordered values, but these arrays are not orderable
> (according to PHP's comparison).  That might indeed not be documented in
> the PHP manual (the language specification appears to be abandoned anyway).


Shouldn't we throw an exception when comparing arrays with <, <=, >, >=
anyway?

- Benjamin

Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties

[Larry Garfield]

On Tue, Nov 30, 2021, at 10:17 PM, Brady Wetherington via internals wrote:
 …It's been merged to master, so you could stand up a build now and point 
 to the many deprecation warnings you're expecting.  I'm not saying send 
 PRs to fix them all, just show real impact rather than theoretical 
 guessing. …
>>
>>
>> That’s a totally fair ask, and I’ll try and get that done and report back. I 
>> think I’m probably going to run into some Laravel problems here, as they 
>> only _just_ came up with a version that will run under php 8.1. I’ll get as 
>> far as I can and let you know - even if I determine that my suspicions were 
>> completely incorrect :)
>
> Okay - good news/bad news/good news -
>
> Good News: I managed to snag an 8.2 build and ran Snipe-IT on it, and
> it worked completely fine. I cheated a little bit - I didn't try to
> make a composer.json that would support 7.4 through 8.2, I just did a
> 'composer install' from PHPv8, and then switched PHP versions out from
> under it. Literally nothing broke at all - I was completely shocked! I
> was so worried that I wasn't testing it right that I had to make a
> quick little test script with dynamic properties in order to force the
> deprecation warning to show up - and it did, so I *do* have the
> latest.
>
> Bad News: That's because later versions of Laravel dump all
> deprecation warnings straight to /dev/null by default. If you
> configure a log 'channel' for 'deprecations', *then* you get actual
> results. One page load (our dashboard page) generated 267KB of
> deprecation warnings. Clicking through most of the main pages of our
> app generated around 3.5MB of them. And these aren't full
> stack-traces, they're just messages like:
>
> "[2021-12-01 03:48:23] local.WARNING: Creation of dynamic property
> Illuminate\Database\MySqlConnection::$readWriteType is deprecated in
> /Users/uberbrady/Documents/grokability/snipe-it/vendor/laravel/framework/src/Illuminate/Database/Connection.php
> on line 1368"
>
> Good News: *Many many many* of those deprecation warnings were repeats
> of the same deprecated thing from the exact same place. And *very very
> few* were from the dynamic properties thing. *None* of the dynamic
> properties deprecations were from our code. Everything was from
> composer dependencies, and only a small handful - so, probably pretty
> easy to remediate when it comes to that.
>
> So the _other_ deprecation notices are a whole other thing, and having
> so many is definitely a drag, but that's a completely separate issue
> from this dynamic properties thing, which doesn't seem too bad so far,
> for us at least. Other folks might not get off so easily, and
> /dev/null-ing deprecation warnings seems like it's kicking the can
> down the road, but, well, *we're* OK for 8.2.
>
> I should note that a lot of my PHP-based CLI tools are spewing
> deprecations everywhere as well, but they at least still work so I can
> perhaps live with that.
>
> -B.

Thanks for the follow up!

Out of curiosity, since it sounds like the dynamic props deprecation rates a 
"meh" on the problem scale for you, what is the most common other deprecation 
you're hitting?  It would be interesting to see how many *unique* deprecation 
warnings a large, real-world application has and compare with other projects.

--Larry Garfield

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

Re: [PHP-DEV] Fork microsoft/php-sdk-binary-tools to PHP org on GH

[Pierre Joye]

Hi Christoph,

On Wed, Dec 1, 2021, 5:48 PM Christoph M. Becker  wrote:

> Hi all,
>
> since Microsoft won't support PHP 8 and beyond, it appears to be
> reasonable to fork the microsoft/php-sdk-binary-tools[1] to the PHP org
> account on Github.  The PHP-SDK is required to build PHP on Windows[2],
> and at least some adaptions to newer PHP versions need to be done[3],
> and there is a PR for building for arm64[4], which may be rejected by
> Microsoft.
>
> Thoughts?  Objections?
>

yes please.

And get ride of the CLA while being  at it.


best,
Pierre

>

[PHP-DEV] Re: Array comparison works completely different than documented?

[Christoph M. Becker]

On 01.12.2021 at 14:56, André Hänsel wrote:

> The official documentation contains a conceptual description of array
> comparison in
> https://www.php.net/manual/en/language.operators.comparison.php#example-113.
>
> Curiously the people who wrote the inofficial spec (I think the HHVM team at
> Facebook?) came to
> pretty much the same result, described in
> https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#relat
> ional-operators:
>
>> If both operands have array type, if the arrays have different numbers of
> elements, the one
>> with the fewer is considered less-than the other one, regardless of the
> keys and values in each,
>> and the comparison ends. For arrays having the same numbers of elements,
> the keys from the left
>> operand are considered one by one, if the next key in the left-hand
> operand exists in the
>> right-hand operand, the corresponding values are compared. If they are
> unequal, the array
>> containing the lesser value is considered less-than the other one, and the
> comparison ends;
>> otherwise, the process is repeated with the next element. If the next key
> in the left-hand
>> operand does not exist in the right-hand operand, the arrays cannot be
> compared and FALSE is
>> returned. If all the values are equal, then the arrays are considered
> equal.
>
> In reality, array comparison works completely different, it is however
> unclear to me how exactly
> it does work: https://3v4l.org/630vG

The point is that $a > $b is actually checking whether $b <= $a.  This
is fine for ordered values, but these arrays are not orderable
(according to PHP's comparison).  That might indeed not be documented in
the PHP manual (the language specification appears to be abandoned anyway).

--
Christoph M. Becker

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

Re: [PHP-DEV] Array comparison works completely different than documented?

[G. P. B.]

On Wed, 1 Dec 2021 at 13:56, André Hänsel  wrote:

> The official documentation contains a conceptual description of array
> comparison in
> https://www.php.net/manual/en/language.operators.comparison.php#example-113
> .
>
> Curiously the people who wrote the inofficial spec (I think the HHVM team
> at
> Facebook?) came to
> pretty much the same result, described in
>
> https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#relat
> ional-operators
> 
> :
>
> > If both operands have array type, if the arrays have different numbers of
> elements, the one
> > with the fewer is considered less-than the other one, regardless of the
> keys and values in each,
> > and the comparison ends. For arrays having the same numbers of elements,
> the keys from the left
> > operand are considered one by one, if the next key in the left-hand
> operand exists in the
> > right-hand operand, the corresponding values are compared. If they are
> unequal, the array
> > containing the lesser value is considered less-than the other one, and
> the
> comparison ends;
> > otherwise, the process is repeated with the next element. If the next key
> in the left-hand
> > operand does not exist in the right-hand operand, the arrays cannot be
> compared and FALSE is
> > returned. If all the values are equal, then the arrays are considered
> equal.
>
> In reality, array comparison works completely different, it is however
> unclear to me how exactly
> it does work: https://3v4l.org/630vG
>
> Do we know how this happened?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

It seems the docs are not accurate in that it will not try to find the
corresponding element in the second array.

By rearranging the keys to be defined in the same order the docs seems to
match the corresponding behaviour: https://3v4l.org/2ta2k

The actual C code implementation of how the arrays are compared (after some
symbol navigation) is the zend_hash_compare_impl() function.
https://heap.space/xref/php-src/Zend/zend_hash.c?r=d3f073e8#2919

Hope this helps.

Best regards

George P. Banyard

[PHP-DEV] Array comparison works completely different than documented?

[André Hänsel]

The official documentation contains a conceptual description of array
comparison in
https://www.php.net/manual/en/language.operators.comparison.php#example-113.

Curiously the people who wrote the inofficial spec (I think the HHVM team at
Facebook?) came to
pretty much the same result, described in
https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#relat
ional-operators:

> If both operands have array type, if the arrays have different numbers of
elements, the one
> with the fewer is considered less-than the other one, regardless of the
keys and values in each,
> and the comparison ends. For arrays having the same numbers of elements,
the keys from the left
> operand are considered one by one, if the next key in the left-hand
operand exists in the
> right-hand operand, the corresponding values are compared. If they are
unequal, the array
> containing the lesser value is considered less-than the other one, and the
comparison ends;
> otherwise, the process is repeated with the next element. If the next key
in the left-hand
> operand does not exist in the right-hand operand, the arrays cannot be
compared and FALSE is
> returned. If all the values are equal, then the arrays are considered
equal.

In reality, array comparison works completely different, it is however
unclear to me how exactly
it does work: https://3v4l.org/630vG

Do we know how this happened?

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

[PHP-DEV] Fork microsoft/php-sdk-binary-tools to PHP org on GH

[Christoph M. Becker]

Hi all,

since Microsoft won't support PHP 8 and beyond, it appears to be
reasonable to fork the microsoft/php-sdk-binary-tools[1] to the PHP org
account on Github.  The PHP-SDK is required to build PHP on Windows[2],
and at least some adaptions to newer PHP versions need to be done[3],
and there is a PR for building for arm64[4], which may be rejected by
Microsoft.

Thoughts?  Objections?

[1] 
[2] 
[3] 
[4] 

Christoph

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