Re: Return type hints

From: Date: Wed, 13 Sep 2006 19:00:12 +0000
Subject: Re: Return type hints
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-25672@lists.php.net to get a copy of this message
>From: "Richard Quadling" <rquadling@googlemail.com> > On 13/09/06, Terje Slettebø <tslettebo@broadpark.no> wrote: > > >From: "Richard Quadling" <rquadling@googlemail.com> > > > > > On 12/09/06, Terje Slettebø <tslettebo@broadpark.no> wrote: > > > > function f(Something $value) /** @return SomethingElse */ > > > > { > > > > // ... > > > > } > > > > > > But one of the first things we are told about using PHP ITRW is to > > > always validate user input and to make sure you only accept what you > > > know to be valid data. > > > > True, and at least with regard to function calls, with type hinting (as you > > mention below), that testing is done for you, so you don't have to, leading > > to less code and syntactic noise (and possibly better performance). > > The issue then becomes what would happen to a value of the wrong type? Getting a fatal error, like with today's parameter type hinting? As an aside: I find it a little ironic that something called "type _hint_" gives a _fatal_ error... (Not even a chance for the error handler to catch it...) It's as if it talks with two tongues: "Oh, yes, we are very liberal - we only _hint_ at what we accept. (Then, with much lower voice) However, we do stop with a fatal error, if you try something else..." "PHP: Desperately wants to be loosely typed, yet desperately wants to be strongly typed...? :)" > You either have the option of using PHP's own internal casting > mechanism, so f(int $i_int_expected) would internally cast the > supplied parameter as an int or you have to produce a WARNING with a > "parameter of the wrong type" message. But then what is passed to the > function? This would have to be determined somehow. I'm not sure what you talk about, here? We already _have_ type hints for arguments... Regards, Terje

« previous php.internals (#25672) next »