Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 22/04/2022 21:47, Mark Randall wrote: The rule that anything typed must be initialized, nullable or not, is clearish enough. It's "clear" in the sense of "it can be described in one sentence". It's not at all "clear" in the sense of "makes any logical sense whatsoever". You could special case nullable, but then it's an extra rule to learn beyond "typed = needs to be initialized". I'm more inclined to the opposite: if reading an "undefined" property is going to be an error, maybe reading an "uninitialized" one should be too, even if you don't declare a type for it. And maybe we should think about exactly what unset() means, and which error you're going to get after you use it - is the property "undefined" or "uninitialized"? Currently, an untyped property becomes "undefined", as though it never existed; but a typed property is still on the object, but "uninitialized". Yet either way, assigning a new value brings back the declared property, not a dynamic one with the same name: https://3v4l.org/nClNs Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 22/04/2022 21:30, Rowan Tommins wrote: Do you not have even a little bit of hope that we could make that less confusing, since we're breaking everyone's old code anyway? I seem to remember we had a discussion years ago about deleting unset on properties, but it was being used for a very popular proxy manager to force them to be routed to __get. The rule that anything typed must be initialized, nullable or not, is clearish enough. You could special case nullable, but then it's an extra rule to learn beyond "typed = needs to be initialized". -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 22/04/2022 18:12, Mark Randall wrote: Accessing an unset property, which currently emits a warning, will instead throw an Error. [...] Re: Case 4, an untyped property without its own initializer is effectively defaulted to null. Imagine you're a new user, learning PHP 9.0, and learning that "public $foo" defaults to null; and if you call unset(), it's deleted from the object, and then accessing it is an error. But then you change it to "public ?string $foo" and it doesn't default to null, even though it's nullable, and accessing it will give you a different error; and calling unset() on that doesn't delete it from the object, but does mean you get an error reading it. Also, there's this non-standard class called "stdClass", which unlike standard classes, you can read and write any property you like without declaring it, and even if you use unset(), you'll never get an error. Do you not have even a little bit of hope that we could make that less confusing, since we're breaking everyone's old code anyway? Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 22/04/2022 14:42, Rowan Tommins wrote: As with your previous RFC, I approve of this in principle, but am frustrated how little time has been spent considering the edge cases, such as the ones I mentioned here: https://externals.io/message/117487#117487 Accessing an unset property, which currently emits a warning, will instead throw an Error. If a property has already been written to via some mechanism, then the property exists and this RFC does not apply, no warning or error should be expected. It's a different responsibility to handle the guards against writing to one which has not been defined (AllowDynamicProperties RFC). Re: Case 4, an untyped property without its own initializer is effectively defaulted to null. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 21 April 2022 22:45:17 BST, Mark Randall wrote: >Internals, > >I have now opened voting on Undefined Property Error Promotion. > >https://wiki.php.net/rfc/undefined_property_error_promotion As with your previous RFC, I approve of this in principle, but am frustrated how little time has been spent considering the edge cases, such as the ones I mentioned here: https://externals.io/message/117487#117487 It seems to me that we've got an increasingly complicated set of states a property can be in, depending on whether it's been declared with a type, without one, or not at all; whether it's had a value assigned to it; whether it's been unset; etc. If I am struggling to follow the distinctions between "declared", "defined", "initialised", "dynamic", "nullable" etc, how will users who start with PHP 9.0 understand why some situations produce errors and others do not? Regards, -- Rowan Tommins [IMSoP]
[PHP-DEV] Re: [RFC][Vote] Deprecate ${} string interpolation
Hi everyone
> I opened the vote on the "Deprecate ${} string interpolation" RFC.
> https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation
This RFC has been accepted. There were 31 votes in favor and 1 vote
against this change.
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: MySQLi Execute Query RFC
Hi Craig,
> https://wiki.php.net/rfc/mysqli_execute_query
>
Thanks. Maybe add (or even start with) an example of mysqli_query(), to
show how "migrating to safer" would become easier? retro-fitting your
example of parameterised query:
```
$sql_format = "SELECT * FROM user WHERE name LIKE %s AND type IN (%s, %s)";
/* ... */
$sql_raw = vsprintf($sql_format, array_map(fn ($s) => "'" .
$db->real_escape_string($s) . "'", [$name, $type1, $type2]));
foreach ($db->query($sql_raw) as $row) {
print_r($row);
}
```
Regards,
--
Guilliam Xavier
Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throwa deprecation notice ?
On 22 April 2022 02:02:58 BST, php-internals_nos...@adviesenzo.nl wrote: >I agree it would be a good idea to run a package analysis, but to be fair, in >all honesty that should have been done for the original RFC, which was >completely missing an impact analysis. That's a fair point, but of course "somebody else should have done it already" isn't a good excuse not to do it now. >3. As for the pattern being common or not - the fact that I found it so easily >in multiple random projects which I elected to test the sniff against, makes >me believe the pattern is not _uncommon_. Since there has been some misunderstanding, the usage I think we need to look for is where a deprecation notice would *not* be useful. In other words, are there people using is_callable in such a way that even if a value like "parent::foo" changes from returning "true" to "false", there won't be anything that needs changing, because the code is equally "happy" with both return values? I freely admit that I can't think of any such usage off the top of my head, but I wouldn't have thought of some of the examples already raised either. If an actual search fails to find such usages, or provides evidence that it is very rare, then I am absolutely in favour of adding a deprecation notice. Regards, -- Rowan Tommins [IMSoP]
