Hi! > I would like to initiate discussion for Object typehint RFC > https://wiki.php.net/rfc/object-typehint
I don't see why it would be important that the variable is an object but not important which kind of an object. There's very small number of things you can do with an object without knowing the exact type. For generic functions, like serialization, there's no reason why they shouldn't be able to serialize integers or nulls or booleans. On the contrary, many objects would not be serializable. For less generic functions, like DI containers, object type is next to useless since you can't just pass any object to implement a service - it should actually implement the required service. So adding "object" does not add real specificity to it. > This feature is developed to provide missing functionality which is needed > and quite easy to introduce. > There are many people which I've talked about the benefits of this > functionality. > > For those who doesn't like the idea and think they won't need neither use > it rather than just saying 'no' they > please say why other people who want to use that parameter type are wrong, > for wanting to do that. They probably think more "strictness" and more checks means better code. It is usually not true per se. E.g. in the RFC examples the type does not seem to be serving a good purpose - it's either wrong (like in the case of json_decode - it won't always return an object), or nonspecific - like in factory, very rarely one has a factory returning just arbitrary objects, no matter what they are. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
