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
>
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