Hi!
class UserPreferences { private DB $db;function getColor(): string { $preferredColor = $this->db->getColor(); if ($preferredColor === 'light') { return '#fff'; } if ($preferredColor === 'dark') { return '#000'; } return $preferredColor; // user has set custom color. } } Assume that both UserPreferences and getInfoPanel code is covered by unit tests. The developer who made that change would run the tests, see the tests pass and then push their code live. At which point, it would cause an error in production, as the string returned would not pass the is_literal check. This would be a complete pain in the butt to fix.
When you write about testing in this database scenario, I find some additional issue: When you try to create pure unit tests you would somehow mock/stubb or replace the database with some test double. In that situation your tests will still pass even if testing the variant that the value comes from the database. Only some (infrastructure or end-to-end) test that covers the business logic plus the corresponding infrastructure by accident would uncover an error.
I wonder if we would need some method to mark a value/variable as non-literal. Or perhaps mark some return value (or input parameters?) in an interface/class as non-literal using some annotation?
That still puts the burden on the developer to think about that issue. But it's probably better than nothing.
Perhaps someone has a better idea? Cheers Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
