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
