Hi! > Again, same for function typehints. NULL is the only possible > initializer there, too. But still we don't take that as a reason to > always allow NULL for them.
For function, non-optional parameters are always mandatory provided. For properties, it is not true - there are no "mandatory properties". I'm surprised how you do not see the different between function parameters explicitly provided and object properties which are never provided when object is constructed and always have to be set manually or use default. They work pretty much in opposite ways here - you can not call function without parameters, and you can not directly assign parameters when creating an object. > Not every property needs the ability to be unset(). Not being able to > unset it is a feature actually. It guarantees that it will always be > available (after the initial set) and does not have to be checked. You convinced me that this feature is actually harmful to PHP - dealing with unset() throwing fatal errors is much worse than occasional empty() check. This is a huge landmine - now any code that unsets object property can return fatal error, and there's, unlike is_null, not even any way to check it. > The timeframe in which it is NULL is usually contained to the constructor. So what? Objects are constructed all the time, and constructors can call any other code. Also, nothing really guarantees the constructor actually has initialized the variable - the constructor author could have forgotten it just as you could have forgotten to initialize it without "no NULL" requirement - so when you are using the API of the object, you can not know if the constructor initialized it or not. And if you're sure your code is right - you don't need null checks anyway, as you know your code never assigns null there. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
