I remember Marcus worked on something like that some time ago. Might still be into SVN or somewhere I think.
Julien On Sat, May 29, 2010 at 9:03 PM, Ferenc Kovacs <i...@tyrael.hu> wrote: > On Sat, May 29, 2010 at 7:34 PM, Zeev Suraski <z...@zend.com> wrote: > > > At 20:28 29/05/2010, Chris Stockton wrote: > > > > My biggest issue as a user is the fatal errors. Why are we blowing up on > >> something that should throw some kind of useful argument exception? I > end up > >> in my applications using instanceof everywhere because their is > important > >> cleanup to be done before the end of the request. For example I can't > afford > >> for php to just blow up in our account setup script, we are reaching out > to > >> multiple non-transactional external resources. Some of our long running > >> command line processes have the same issue. I am all for type hinting > but > >> the fatal errors or "catchabale" fatal errors are just silly. Exceptions > >> make so much more sense to me. > >> > > > > IMHO we shouldn't be getting to any kind of fatal error/exception > > situation, which is why I like the idea of auto-conversion plus E_STRICT > in > > the 'weird conversion' scenarios (the API function shouldn't care - it > got > > what it asked for; The caller would get notified that he passed > something > > that probably doesn't make sense). > > But as to why errors and not exceptions - we have a guideline that > language > > constructs don't through exceptions. It's up to users whether they want > to > > use exceptions or not. > > > > > > Zeev > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > I'm thinking about the type hinting in php for a while, and there is my 2 > cent about this. > > As an API developer, I need a way, to easily force my input into a proper > type, with ease, without dataloss, and without code duplication. > As an API consumer, I don't want to bother much about my API calls, as long > as my passed arguments are in the accepted form(I don't want to > convert '123' into 123), and I don't want to create yet another custom > error > handler, to fetch the potentially triggered errors, and I cannot allow, > that > one unhandled catcable fatal error ruin my application. > > So basically I need type jugling(weak type hinting) + exceptions instead of > catchable errors. > But I know that the core should't throw exceptions, so we can't go to that > direction. > > What if we introduce a new spl interface, which propose auto boxing for the > scalar types + exceptions for the type missmatch. > I mean, if you call that class with scalar arguments, the scalar values > will > be converted to the matching spl class instance. > This way, you could hint your types for the interface without forcing the > api consumer to bother to convert '123' to 123 before passing it to the > method. > But if the consumer passes '123abc' when I'm hinting SplInt, then it will > throw an InvalidArgumentException or such. > > So for example: > > class foo implements WeakTypeHinting{ > public function bar(SplInt $baz){ > return $baz++; > } > } > > $foo = new foo; > echo $foo->bar(1); > // 2 > echo $foo->bar('2'); > // 3 > echo $foo->bar('3a') > // InvalidArgumentException > > Feel free to discuss. > > Tyrael >
