Well, the thing is objects and arrays are complex types, so you can't
pass anything exept array to an array type hint, it just dosen't make
sence. Not everything can be converted to array and vice-versa. Same
with objects - every object is it's own type.
But the primitive types behave differently. It's because that they are
primitive, they easily convert from one to other back and fourth. I
don't see the need to be strict as really that feature will be used so
rearly, that it doesn't cost the effort. Really, any framework using
strict hints? How do you expect them to receive data from HTTP and
databases. It would require to write conversion rules for all data
they receive so it would be passed in the right type to the API. It's
just nuts.
The more realistic way is you define a function/method with the params
and wrap it into try {} catch {} block. If data is converted with the
data loss: for exmple you expect a numeric ID, but get a string of
chars - fetch the error and display an error message of a wrong ID.
Just the same way we do now - check for is_numeric and display the
error. This way the feature will be used. Strict types for dynamic
language is a non-sence.
Stop making things more complicated.
2010/8/11 Derick Rethans <der...@php.net>:
> On Wed, 11 Aug 2010, Johannes Schlüter wrote:
>
>> On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote:
>> > type hinting
>>
>> For the record: I consider the current implementation as (one of) the
>> biggest mistakes in the last ten years.
>
> I will try to sum up my view point once more:
>
> 1. right now we *have* strict type checks for classes and arrays in the
> form of "classname" or "array"
> 2. the strict scalary type hint patch reuses this same syntax in the
> form of <type-name> to do the same thing in function arguments
> 3. we have casting type hints in the rest of the code in the form of
> "(int)".
>
> Some people don't like strict typehints, but the syntax as it currently
> is regarding type hints is *consistent*. Now, to allow both strict and
> casting hints, the logical step seems to be, to give the weak typehint
> advocates their tool as well:
>
> 4. We add casting typehings to function arguments in the form of "(int)"
> so that that is consistent as well. We would need to figure out
> whether we want:
> a. warnings on conversions (my choice)
> b. no warnings
>
> This:
>
> - keeps the syntax consistent
> - allows both strict and weak typehints
>
> Should make everybody happy (enough), right?
>
> regards,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
