Hi all:
On Wed, Jun 9, 2010 at 1:59 AM, Daniel Convissor <
dani...@analysisandsolutions.com> wrote:
> Hi Lukas:
>
> On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
> >
> > Same deal as E_NOTICE. Either you care about them or you dont.
>
> Exactly. The type hinting situation is unique. It is something that
> applications will frequently want to handle gracefully in order to
> provide useful error messages. A new error level is needed, as is an API
> / function to obtain the failed parameter names, desired type and passed
> type.
>
I personally don't get this error handling and weak type hinting discussion,
looks like a mix-up of type hints and input validation.
To me, type hints are a contract between an API and the consumer of the API,
reason being that it makes things a lot easier on the inside of that API
call and errors caused by misuse are caught early.
For those that don't want this contract, don't use it.. By default PHP will
behave just like you want, namely: type less.
But to me, that is not a good way for API's that are used by several
thousand developers that probably don't check the php doc every time they
use a function, and do something human; mistakes.
When PHP 5 added support for this, that made my day, even if it wasn't
complete.
It is one of the things that made PHP's OOP support a lot more on level with
other languages / platforms, and I think it is a strength that it behaves
like other platforms for those that want to use it.
So sorry, but I think Lukas' & Zeev's proposal is the wrong approach, it
will make this useless for the very people that wanted it in the first
place.
Example:
function fetchById( int $id, bool $asObject = true )
If weak type hints are accepted, type hints would be useless in this case as
consumer can do something strange as fetchById( true, 'foo' ) (Obviously I'm
not saying anyone would do this intentionally, but in a large application
you might not have full oversight and can unintentionally pass variables of
wrong type or in wrong order causing issues to surface much later as there
are no strict type checks that would detect the mistake immediately while
developing).
--
One solution (if weak type hinting is really needed) is to go back to Ilia's
proposal for virtual types and for example extend it with "wint", "wbool",
"wstring", "wfloat" and similar (it could just as well be "~int", "int_w" or
"int_cast" for instance) for cases where you want to accept type by value.
This casting should be done with current type juggling rules for
consistency.
But adding cast support like this would make the whole catchable cast
error's discussion re appear. And those probably involves a lot more
overhead then handling such cases yourself inside your API functions using
exceptions, so I don't personally see any gain by this.
So to avoid that, I would say Derick's proposal to allow "function foo(
(int) $bar) { } // auto-cast to int" is superior as it will avoid that
discussion/issue, keep it simple & not be misunderstood as a means of input
validation.
- AR
