On Fri, Jan 2, 2015 at 9:54 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > >> I am not sure about that. Parameters handling is one specific case, >> userland parameter handling even more. It could be a good move to do > > Making internal and userland parameters work differently and having > scalar type errors behave differently from object type errors by having > one throw exceptions and another errors looks like a mistake to me. It > only makes handling errors harder as you'd have to handle two types of > situations instead of one.
I was not clear, sorry. Parameter handling in general as described in this RFC are a special case. This addition is somehow different from other arguments handling we have, whether it is used for internal functions or userland. I only see Exceptions even more useful in userland code. There is no change per se to existing functions. Or to say it in a better way, I am not keen to begin to chagne every 2nd internal function to apply this new RFC, it could cause some bad headaches. However, new functions and the likes, explicitally relying on this RFC, may be a good candidate to have a different handling for bad argument. >> that as a 1st step, with this RFC. > > I don't think "1st step" is a good approach here. The language should > provide consistent expectations, including about what happens when you > pass certain data to it, including error conditions. If we have > different types of error conditions between internal and userland > functions, it would not be a good thing. Agreed, but still. New userland codes could have huge benefits if we allow that. But changing every internal function may have a bad impact. > We should make all parameter handling work the same way - so if you pass > a parameter and it does not match the expectations, you know what you're > getting. If it works one way to internals, another for user functions, > it would only make it harder to handle. Right again. Still not sure about the perfect solution without impacting too much existing userland code. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
