First a general note on the complete nullability first: It is not up to us as language designers to decide whether it is good practice to use nullable properties or not. It is supported by many systems since ages (e.g. SQL where nullable fields are also not recommended but heck they are useful) and it is common practice in PHP. Hence, there must be support for it. That does not mean that it is endorsed in any way by us, it is just there for people who need it for the same reasons they needed it in the past 20 or so years.
I also would like to repeat that ...
final class A {
private int $x = null;
}
... aligns perfectly with PHP 5+ syntax for optional arguments, is
unambiguous (in terms of interpreting, reading, understanding, and
writing), does not introduce a new syntax/keyword (e.g. /?int/) just
because the cool kids from Facebook have it and -- last but not least --
developers can use /isset/ and /=== null/ instead of weird checks like
/empty/ (super dangerous), /=== -1/, /=== 42/, /=== 'invalid'/, or ...
you get the picture.
Null is perfect for nothing and that is what null is: nothing.
On 3/18/2016 12:48 PM, Marco Pivetta wrote:
> To sum it up, the RFC has one major problem: it focuses on the WHEN
> assignments happen, rather than just checking WHAT is assigned.
>
> I think the scope of the proposal needs to be reduced strictly to type
> checking.
>
I know I am repeating myself but Marco summed it up perfectly and I
agree to 100% with him. The checks should start with the *first userland
assignment* and continue from there on to check the type *upon userland
assignment*.
I am stressing the /userland assignment/ because of previously mentioned
functionalities of some extension like /mysqli_result::fetch_object/ or
/PDOStatement::fetchObject/ who should be allowed to assign completely
different types. Casting and such should be the problem of implementers.
(The maintainers of the extension could of course implement auto-casting
for scalar types like /int/ but more than that seems like overkill too me.)
On 3/17/2016 11:32 PM, Andrea Faulds wrote:
> Disallowing references here might make users more aware of which
> functions take parameters by reference, and avoid accidentally
> modifying values. So this part of the RFC might be a good thing.
>
This is a noble intend, however, it makes the code harder to read and it
requires silly assignment operations just to get something done. Doing
stuff like ...
$sort_me = $this->array;
sort($sort_me);
$this->array = $sort_me;
... is an absolute no go, just look at it, however ...
$this->array = array_sort($this->array);
... would be awesome but the forces against clean-up and deprecations
are strong in the PHP world.
https://wiki.php.net/rfc/consistent_function_names
We could alter the lists use (e.g.) a /ref/ keyword for stuff that
requires stuff to be passed by reference and introduce new ones without it:
- /array_sort/ ~> *new*
- /array_ref_sort/ ~> /sort/
This would achieve the same goal but people could go for what they want
while making them more aware. Plus, there is an upgrade path if
references are to be removed from PHP at some point in the future.
Well ... I think this idea is also more noble than it is really
applicable, simply because there are still too many functions left that
do not need a rename but a reference. :P
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
