I'd say that I agree on this, I would like to see the conversion rules
cleaned up and made more clear. The idea of emitting e_warning or
e_strict on conversions with data loss throughout the language is very
appealing. Maybe we really need to do that so conversion rules and
type hinting rules to work the same?
2010/5/28 Larry Garfield <la...@garfieldtech.com>:
> On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
>> At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
>> >On the other hand, auto-casting used to be my favourite until I
>> >glanced over the conversion table; it's not just regular casting, it
>> >has different rules. I wouldn't want to be the one going over that
>> >table when writing code against a certain API, I should only need to
>> >see the documentation.
>>
>> Tjerk,
>>
>> I think you have a nice idea about E_STRICT, except it makes much
>> more sense with auto-conversion. That is - in case of 'fail' - we'd
>> still convert, and emit E_STRICT (or E_NOTICE). That means that the
>> API developer will always get the type he expects, while the user
>> will be guided in the right direction in a friendly PHPish manner.
>> The conversion table is up for discussion, BTW. If most people
>> prefer that it's more similar to PHP's existing auto-conversion rules
>> (that appears to be the case) we can certainly do that.
>>
>> Zeev
>
> I'm not 100% sure I follow, Zeev. Are you suggesting:
>
> foo (int $a) { }
>
> foo(1); // Works, no message
> foo("1"); // Works, no message
> foo("1a"); // Emits E_STRICT or E_NOTICE and casts to a 1
> foo(array(1)); // Fatal
>
> I could get behind that. In fact it also suggests that we could (later?)
> alter the normal casting rules so that if you do a lossy conversion you get a
> notice/strict in any case. Something to chew on.
>
> I like that idea, as the "purely strict" typing that's in HEAD right now I
> find
> worse than having no scalar type checking at all.
>
> --Larry Garfield
>
> --
> 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
