(after clarification on what Zeev meant, there was a bit of a follow up that I'm posting as reply):
On Wed, 11 Aug 2010, Zeev Suraski wrote: > How is it different from having both options? Given enough time isn't > it exactly the same thing? Argument verification should not be a > customizable feature. > > Collecting the info (for documentation purposes and reflection) is > something else and I think that's fine - and then the only question > that remains is the syntax (which IIRC includes modifiers for > strict/weak that we should probably clean up). > > If I understood the idea behind the patch, you want to pass on the > argument validation function to the engine on startup. That means > that overnight there'll be a version of PHP supporting different > validation functions. Or am I missing something? Well, PHP wouldn't support it directly. But it would allow a zend extension like Xdebug to provide a strict validation function while debugging and development. Very similar to the overloaded zend_error_cb and var_dump() function. During production you'd obviously *not* have a caster/strict type validator. It seems quite clear that "you lot" don't like a strict type check; whereas another lot don't like a casting typecast. I'd be much for your option #3 (no scalar type hint/cast/strict check by default); but still allow other tools to access the information that's been supplied by the parser. That doesn't even necessarily have to be an argument validator/cast/type check of course; but simple introspection tools that makes marshalling data to other more type-sensitive data sources. I've been working with MongoDB here for the past week, and that'd be such a data source. Derick > At 21:38 11/08/2010, Derick Rethans wrote: > > On Wed, 11 Aug 2010, Stas Malyshev wrote: > > > > > So I'd propose doing the following: > > > > > > 1. Moving parameter typing to a feature branch (by branching current trunk > > and > > > then rolling back the typing part in the trunk). > > > 2. Starting 5.4 alpha process after that basing on trunk. > > > > > > Any objections to this? > > > > A little bit; yes. There is indeed 0 consensus for having the strict > > typehints. However, instead of removing it altogether, and instead > > answering every mail in this thread :P, I wrote/am writing a patch that > > removes the hard type checks. It however keeps the parsed structures and > > reflection API for it. In this sense, they're actually real hints. The > > patch also adds a mechanism similariy to the zend_error_cb mechanism so > > that extensions could override the argument type checking. As my use > > case for strict checking is development I'd be happy to just move the > > hard checks into an extension. I could even offer a soft check. It also > > allows some type inference which might be useful for webservice > > introspecition generation. I am sure SOAP might have some benefit of > > this, and I know that at least pecl/dbus does. The patch is attached, > > but not ready (I haven't remove the hard checks yet because things got > > busy at work). > > > > Derick > > > > -- > > http://derickrethans.nl | http://xdebug.org > > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > > twitter: @derickr and @xdebug > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
