Waldeedle The factory method in the DB_DataObject class has a PHPDoc where the return type is given as a DataObject|PEAR_Error, however the class name is DB_DataObject. This results in a lot of PHP0416 when accessing properties such as id, here is some sample code to illustrate my use-case: $users = DB_DataObject::factory('users_table_name') $users->id = 1 Here I would receive a "Undefined property: DataObject|PEAR_Error::$id (PHP0416)". Another issue is that some of the functions in this monolith use the DB_DataObject class as a function arg but again because of that PHPDoc it flags all of them as if they are using the wrong type (The code is completely functional). Example: $userRecord = DB_DataObject::factory('user_table_name') while ($userRecord->fetch()) { $user = new User($userRecord) } where class User function __construct(DB_DataObject|null $object = NULL) { //implementation ... } DB_DataObject is the right class however due to the PHPDoc, I am seeing "Argument '1' passed to __construct() is expected to be of type DB_DataObject|null, DataObject|PEAR_Error given (PHP0406)". For the problems in 1 and 2, would there just be a method to exclude a class from identifying problems? Or silencing any hinting around the return from the factory method? A final thing which honestly might just be the code base itself needing to be cleaned up. The PHPDocs have @param bool|FALSE or @param bool|TRUE and @param null where the TRUE or FALSE or null define the default value for the function arguments.
Waldeedle Revisiting this, documentation would suggest that #1 is just due to misuse of the framework in this team's repo. Classic. I guess that would also correct #2 since I could type the output of that class as just the DataObject in question. How do you feel about #3? I feel like this is not standard and is just a dev trying to provide insight when the function signature is already returned. It's not needed.
JakubMisek Waldeedle We will handle TRUE, FALSE, and null as expected (#3). The misuse of DataObject instead of DB_DataObject will be tough to recognize (#1, #2). Usually, I'd suggest to report it to the developer of that code or give him a pull request on GitHub.
Waldeedle Sounds good to me! Haha I'm on the team so I'll probably be the one correcting that. Just new to PEAR so didn't realize our usage of it was counter to the documents.
JakubMisek adding, #3 is regular PHP 8.2 notation. true, false, or null are valid type names so we should accept them if we're not doing that yet.
JakubMisek A quick workaround for #1 #2: Add a dummy .php file with the following content <?php class_alias("DB_DataObject", "DataObject"); The editor should pick the information from the file and thread both types as equal.
