Bishop, Pardon me for saying so, but I don't think you're on to a huge scoop here. Scalar type hints - of all the kinds we've been talking about here, be them strict, weak or coercive - can be easily emulated with a couple of lines of code, we all know that. It's been known for years that strict hints are is_*() else error equivalent, that weak hints are (mostly) just casts, etc. Saying the class type hints can be emulated with is_a() calls wouldn't shock anybody either.
However, the conclusion you seem to draw from that, few language designers would agree with. Adding first-class, reflectable, analyzable syntax - is worlds apart from the situation today - regardless of what type of scalar hinting we talk about. Once we introduce language-level syntax for this pattern, usage will *explode* compared to what it is today. Explode, not increase. Tools would be updated to support (and take advantage) of this new data - in a way they can't practically do with userland 'emulation' of this behavior. Best practices will be updated. Doc formats will be changed. Etc etc. Last, note that you only focused on userland functions. Things are a bit different with internal functions. The different proposals on the table all propose to change - in one way or another - the way internal functions behave. This is much less intuitive to emulate using userland code, for obvious reasons. So no, I don't think we're making a bigger deal out of it than it is. Scalar type hints are a huge deal, and the fact you can emulate them in userland code today doesn't change that in any way. Thanks, Zeev > -----Original Message----- > From: bishop.bett...@gmail.com [mailto:bishop.bett...@gmail.com] On > Behalf Of Bishop Bettini > Sent: Wednesday, February 18, 2015 2:18 PM > To: PHP internals > Subject: [PHP-DEV] Nightmares on type hints, annotations, and aop... > > After a spate of literal coding nightmares, I woke needing to commit these > thoughts to the list. These may have been raised before, I can't > remember, > these debate has been raging for so long. > > > THING 1: Hints are just is_* wrappers > > function f(scalar $s, int $i) { } > > effectively is sugar for: > > function f($s, $i) { > if (! is_scalar($s)) throw new \InvalidArgumentException(); > if (! is_int($i)) throw new \InvalidArgumentException(); } > > > THING 2: Hints are truthy callables > > function my_mixed($m) { > return (null === $m || is_string($m)); } function f(is_scalar $s, > is_int $i, > my_mixed $m) {}; > > > THING 3: Pre- and post- blocks to define contracts, establish formal join > points, with or without hints from above > > function f($s, $i, $m) > before { > if (! is_scalar($s)) throw new \InvalidArgumentException; }, inside { > $fp = fopen($s, 'r'); > return [ $i, $m ]; > }, > after ($retval) { > assert(is_array($retval) && 2 === count($retval)); }, finally > ($retval) { > fclose($fp); > if ($retval instanceof \Exception) { > // I got here by an unhandled exception > } > } > > weave('before', 'f', function ($s, $i, $m) { > syslog(LOG_DEBUG, __POINTCUT__); // is 'f' > } > > > I had to get these off my chest. Forgive me their implementation > ignorance. > I am yet tired and uncaffeinated. To the void I commit their bodies... > > bishop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
