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.

[gzhegow1991]

You dont even understand to point of the world you live for whole life.

World prefer cheap
World prefer super
World prefer simple
World prefer one-action
World prefer reputation over knowledges
...more

Your PROFESSIONAL (not PERSONAL) purpose is to know "what result world get when follow those points".

Cheap means salary becomes lower
Super means expectation become higher
Simple means "once task to fix something appears - nobody knows HOW to fix and nobody dive WHY" but development time WILL (without asking of anybody) become smaller
One-action means - fast entry threshold, but additional development time
As we see here - when Marx dead, people created Liskov and start to believe in new God because of... maybe nice name or something. SHE SAY NOTHING NEW. SHE SAY WHAT THINGS WAS BEFORE HER. And btw i personally think SHE NEVER SAY.

And i prefer to stay you in your swamp.
With all your followers.
Like most of the sober people do.

We dont talk about PATTERNS USEABILITY. We talk about "HOW YOU FORCE THIS USEABILITY". And this forcing changes nothing, but pattern is correct. And your rules makes your own recommendations HARDER TO IMPLEMENT. But you have experience in explanation mistakes using high-reputation persons. You're, sir, communist.

Personally i like communists. That communists that was my parents and grand parents. But you're neo-communist. Know propaganda and how to use it. But cannot "extract reason", and with recommandation to move TALK to TRASH of tonns of opinions.

Instead, i expected from language support team only "ask this idea on next meeting". But you say enough to decide "its unchangeable swamp, and should be destroyed"