Hi! > As far as "introduce completely new concept, not existing in PHP at > all", that's the entire purpose of an RFC. That's what we're doing right > here. We're talking about introducing new functionality and features > that may make people's lives easier. So to discuss the feature, yet > limit it to not including new functionality, is rather odd...
You can not both say "it works just like method parameters" and in the same breath say it needs the concept of dynamic initializers which never existed in PHP and which BTW was not introduced in the RFC either (and which won't solve the problem you're trying to solve anyway). > You always have the possibility of having null before the object is > constructed. That's given. Not before. While initialization is running. Which can be quite a complex process. E.g. look at SoapClient class - it parses whole WSDL in the constructor. Imagine you implemented something like this - there would be a bunch of things happening while object is being constructed. > But after the constructor finishes, you can actually guarantee that the > property is never null. For example: You can only guarantee it if you know ctor actually assigned the variable, but there's no way to check it in the code. I.e. if you manually reviewed the code, you can know it, but declaration itself in no way guarantees it, even though you were thinking it does. So for it to be actually useful, you need to know that ctor has already finished working and that that ctor actually assigned value to this property. And if you are third-party library using this class as an API, it's not very useful for you unless you code-review all third-party libraries you use. Declaration itself does not guarantee it, even if it looks and is promoted as if it did. > In PHP, inside foo(), $bar will *never* be anything except an instance > of Bar. It's not possible. Trying to pass Null would generate a > catchable fatal: http://codepad.viper-7.com/Le3jC1 Again, for parameters you MUST provide parameter to call a function, otherwise function would not be called. So there's no way the control can enter the function and $bar not be assigned to instance of Bar, whatever the code around it is doing, however crazy it is. On the contrary, it is very easy to find scenario where property is declared as "public Bar $bar;" and still contains null. Unlike parameters, again, the declaration itself DOES NOT guarantee the property is not null. > This concept is just an exception of that. After construction, if the > property is not declared with = NULL, it's never allowed to be set to > it. Simple as that. It's the same thing as setting the setter to a > function which type hints against Bar $bar instead of Bar $bar = NULL; But that's not very useful. Who cares if it can't be set to null if it can still be null? You'll have to check it anyway. Or, even worse, you'll rely on your own insistence that it can not be null and get fatal error in production code. > As far as unset failing, we already have the ability to do that right > now with __unset(). All this is doing is applying it to the implicit > declaration when providing a type-hinted property variable... With __unset, you will have to specifically write code to do that. Here, it is a side effect of a declaration that has nothing to do with unset and it is completely unobvious to 99.999% of the users that this is what will happen. > No. The whole point of this is to make defensive coding easier. We can But you don't make it easier if you're making promises you can not keep, such as "this value will never be null". -- 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
