Hello! > As I mentioned, I think that we have to inform the caller about the problem > (be either a type or a conversion mismatch), so the only options to trigger > an error, or throw an exception. > I like the exception idea better, because it can be easily handled localy > (no need to register a global error handler), but as the core devs said, it > isn't allowed to throw exceptions from the core, so this is why I think, > that the weak type hinting should be implemented as an spl interface. > This way we could even support array - ArrayObject conversion too. > > http://wiki.php.net/rfc/splweaktypehintingwithautoboxing
I'm not sure what is being added by using the SPL interface except a way to justify throwing exceptions on type mismatch with data loss? The only reason I can think of for throwing exceptions in this case would be data validation purposes, which I think is not the intention of type hinting, and also not the intention of exceptions (users inputting bad data is not an *exceptional* occurrence imo). Is there some other reason / use case for wanting exceptions? So, I mean, where is the use case where '123abc' will be passed to a type-hinted field where you could catch the exception and do something meaningful to carry on with the execution of the program other than simply error-ing out? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
