Remove signature strict checking for PHP internal classes

[gzhegow1991]

Description

ReflectionClass could return isUserDefined() or not

Most angry case for me when migration old goddamn projects to PHP8 from old 7/5 is REQUIREMENT to reimplement ANY class that based on PHP internals like \ArrayAccess, \Countable, \Serializable, \IteratorAggregate and so on

Damn, once i copy 700 classes (and then create 300 factories) just to add mixed to return type of ->offsetGet() and ->jsonSerialize()

Please, add the flag in PHP 8.5 config (or what) to ignore signature check for Internal classes only. Please.

Also would be great if your team write DLL that can be installed on PHP 5/7 that ignores (just ignores!) property types and attributes from PHP8 giving ENOUGH code migration support, then we can copy PHP8 class and... just use it!

Accidentally your "community RFC" forces all the world to rewrite their own projects from scratch.
And accidentally (!) yes, then "GoLang" start to be VERY ATTRACTIVE to half of the people.

I know that this reply could appear 5 years before... But it has to appear.

[Girgias]

This is a language change that requires an RFC, if you feel so strongly about please email the internals mailing list with your proposal.

[gzhegow1991]

Maybe you just implement online service for votes right here?

I propose maybe 10 ideas (last five years) and all 10 ideas is stucked nowhere because i have to subscribe mailing list and then impress unknown people from whole world (alongside problems with non-stop spamming my email of talking those people about how to run php scripts)

Isnt it your opportunity to make language better or mine?

And because of my own stupidity it seems for me like "the people accuire in GBritain who just dont want PHP to be progressive" - they kill the language and freezes it growing... I dont understand only one - why devs still pretend "things going fine"

[Girgias]

This is the process, you do not get to dictate how we run the project.
GitHub issues don't have the visibility that a mailing list has.

If you are uninterested into following the process, that is not really our problem, nor is it our job to tailor the process just for you.

I would recommend reading Open Source is Not About You

[gzhegow1991]

I'd recommend to compare the stats of nowadays games, yes PC games.
Compare the quality of old games and new games. And decide.

ANY place where "voting" is primary way to decide becomes old dead scratch.

Projects is growing ONLY when main developer is the man who can search interesting ideas and then redelegate it to community votes. Headless projects is dying anywhere!

First of all the PRO looking something interesting, then MIDDLE speak about, JUNIORs usually only reading and its correct.

Headless behavior is the safe only for one thing. The LAW. When people start to drain money from company because its solutions make things worse. THATS WHY open source is presented. And not to dive headfirst into it

[erickcomp]

You can use this code to check for internal classes:

<?php

class C1 {}

var_dump(
    (new \ReflectionClass(C1::class))->getFilename(), // returns the filename of the class declaration
    (new \ReflectionClass(\ArrayObject::class))->getFilename(), // returns false for internal classes
);

P.S.:
I think that Rector PHP could help you boring tasks like this

[gzhegow1991]

You can use this code to check for internal classes:

getFilename(), // returns the filename of the class declaration (new \ReflectionClass(\ArrayObject::class))->getFilename(), // returns false for internal classes ); P.S.: I think that [Rector PHP](https://getrector.com/documentation) could help you boring tasks like this

thanks, but its not the point

point is i should rewrite manually whole project but it changes nothing in project behavior

simple INI checkbox could solve the issue of migrating from older PHP to newer PHP, without touching any line

backward compatibility ("i wrote function for the project, then i've met new old project and i want to use my code") its like more complex task, but ignoring props/attributes do half of the job, because other things is support ?-> and ??=, and maybe ( ?? throw new) stuff, also is_callable() behavior changed requires maybe minutes/hours, but properties/attributes need DAYS.

Most often of the problems is refactor whole class without a reason.

And there's case that cannot be solved - writing code libraries. Supporting 2 different libraries in two different folders with requirement to switch it between projects is MUCH MORE complex than work with one library. Today i create subnamespace in certain folder like MyNamespace\PHP7\MyClass and then use factory like Lib::newPhp8(MyClassPHP8::class). Its a tricky little bit, but its better than copy whole library to second folder and then use 2 libraries each time new projects becomes my table.

I've just created yesterday array object (implements \ArrayAccess) for my PHP7 library, and i should to duplicate class because ->offsetGet() needs return typehint mixed that CHANGED NOTHING.

I agree with return typehints, that was added by developers in their projects. I dont agree with useless internal typehints explained in docs.

[cmb69]

Most often of the problems is refactor whole class without a reason.

Well, if proper adherence to the Liskov substitution principle is "without a reason".

No return type is the same as mixed|void, and if the parent class/interface has mixed, you would widen the return type, what is not type-safe.

simple INI checkbox could solve the issue of migrating from older PHP to newer PHP, without touching any line

Changing language behavior based on INI settings has long been recognized as a bad solution, because it is confusing. So this will not happen.

Also would be great if your team write DLL that can be installed on PHP 5/7 that ignores (just ignores!) property types and attributes from PHP8 giving ENOUGH code migration support, then we can copy PHP8 class and... just use it!

And what about those who can't even use a DLL, because they're running on POSIX systems? Your suggestion doesn't make sense (besides that it would even be more confusing to have different language behavior based on the php8.dll).

Feel free to build your own PHP (you can fork and use https://github.com/cmb69/php-ftw, if you like). Or bite the bullet, and make the changes (Rector has already been mentioned).

If you want to continue the discussion, write to the internal mailing list. This is not the proper place for such discussions, as has been pointed out already. I'm closing this ticket as WONTFIX. An RFC can still overrule this.