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
