I think we should stick with E_WARNING for now. If you want to use
exceptions you can throw one in a custom error handler. I can change
about 4 lines of code in my patch to have it emit an E_WARNING easily.
On Thu, 2008-01-03 at 19:49 +0100, Jochem Maas wrote:
> am I the only one to consider E_FATAL (as generated for class typehints) makes
> type hinting useless - given that there is no compile stage at which to catch
> typehint related mistakes. which means there is no way to trap the issue and
> offer some useful/user-friendly feedback to the user (in practice it usually
> means the white page of death for a site visitor)
>
> E_WARNING also is not much better given that one would assume the
> function/method
> that was passed incorrect variables (according to type) wouldn't run.
>
> would an exception not be the most suitable thing to generate on a typehint
> error?
> to me anything else makes typehinting in production environments pretty much
> unusable
> unless one write code like so:
>
> function foo(Foo $f) { /* do foo stuff */ }
>
> $f = getFoo();
> if ($f instanceof Foo) {
> foo($f);
> }
>
> now the issue with such code is not that it is alot more verbose than might
> strictly be needed but that the instanceof statement makes the typehint rather
> superfluous.
>
>
>
> Tomi Kaistila schreef:
> > Yes it seems PHP will omit E_WARNING if you omit an argument.
> >
> > (Had to actually check.)
> >
> > Not a bad choice for an error and probably also easier to manage when you
> > are
> > dealing with complicated error handling in large applications.
> >
> > I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the
> > simple fact that they are ignore by a major portion of PHP developers and
> > to
> > use them would prompt a high risk of people writing bad code.
> >
> > Also, now that you mentioned abstract classes, type hinting might also be
> > useful with interfaces.
> >
> > Tomi Kaistila
> > PHP Developer
> >
> > On Thursday 03 January 2008 19:21:21 you wrote:
> >> I think E_WARNING would be appropriate. That's what happens when you
> >> omit an argument to a function right?
> >>
> >> And about function return type hinting, I don't think it would be as
> >> useful as parameter type hinting, but it would be useful. Mostly for
> >> stuff like declaring an abstract function in a parent class that must
> >> return a certain type.
> >>
> >> class a {
> >> abstract public function getNumber() returns int ;
> >> }
> >> class b extends a {
> >> public function getNumber() {
> >> return rand() * 3463 ;
> >> }
> >> }
> >> class c extends a {
> >> public function getNumber() {
> >> return 'I\'m going to mess everything up by returning a
> >> string.' ; //
> >> Would cause error with type hinting.
> >> }
> >> }
> >>
> >> On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote:
> >>> Hello everyone
> >>>
> >>> I figured I would bring my opinion in to support of Sam's request for a
> >>> more complete type hinting feature. Namely I am interested in the support
> >>> for hinting scalar types on function and method arguments and I am sure
> >>> it is safe for me to say that I speak for a lot of people. Most people
> >>> that I know find the current type hinting, while useful, ridiculous
> >>> because it looks like the job was left unfinished for whatever abstract
> >>> reason.
> >>>
> >>> In my opinion type hinting should definitely be allowed for scalar
> >>> values. As for return types, I am not so sure. So far I have found no use
> >>> for such a feature in my own code, so I won't comment on it. If it is
> >>> added, I welcome it for those who find it useful but if it is not added I
> >>> will not loose sleep over it.
> >>>
> >>>> I was thinking at something along the lines of objects also for
> >>>> instance: $i = new Integer(33);
> >>> After my own experiments with the subject I concur that while it can be
> >>> made to work, it is not only a bad idea (for the reasons mentioned
> >>> earlier) it is also redundant and just unnecessary. There is a lot better
> >>> way to accomplish the same and that by allowing scalar values to be
> >>> hinted. It is simpler, cleaner, and easier to implement.
> >>>
> >>>> What if type hinting just generated an E_NOTICE. Nothing more for the
> >>>> time being.
> >>> Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since
> >>> if I write a piece of code that hints that the argument for a-whatever
> >>> method needs to be an integer it seems useless if the user of my library
> >>> can avoid the issue just by supressing lesser errors and those who do not
> >>> need to write extensive error handling code to respond to this sort of
> >>> error (if they indeed deem it necessary to do so).
> >>>
> >>> While hinting is, and should remain, optional, when it is used it should
> >>> be enforced. After all the user of my library has the option to dump it
> >>> and go for another library that does not force types. That is the beauty
> >>> of having options.
> >>>
> >>> Tomi Kaistila
> >>> PHP Developer
> >
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
