Hi!

> Andrea already said that we would not use it for untyped properties,
> hence, no BC.

Again, it's not that simple. Properties are not local. That means any
code that can deal with a class that may have typed properties (which
may be library class, for example, so you don't even know what it has
inside) has to deal with the possibility of it being of the new type. So
if the old code uses is_null($object->foo) as means to check if the
value wasn't initialized, and it's no longer null, then that code is
broken and needs to be rewritten. That's a BC break. Yes, it will never
happen if you never use typed properties, and never use any libraries
that might use typed properties, but then what's the point of the whole
thing? The point of BC is that if you don't use new features, you don't
have to change your code and it will keep working. With the proposed
solution, it won't be the case.

> It is not the same as null, very similar, but definitely not the same.
> Think of it in DB terms:
> 
>   | table |
>   | ----- |
>   | id    |
> 
>   SELECT name FROM table;
> 
> That's not null, it's not defined (undefined, unset, ...). In other
> words, null is a value and undefined/unset a state.

"name" is not a value, as in if you do that in SQL, you don't get a
value, you get an error. Same as if you wrote "please can I haz a
pony?". It's just something the SQL can not give you, so it produces an
error. What is proposed here, however, is a PHP type, not an error.
That's a different thing - if you have a variable, then you have to have
a value, and if you have a value, then you have to have a type.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to