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
