As man from userland, I totally agree with Larry. I see completely no sense
in raising error when a safe conversion can be done. And I don't like
current implementation at all. It is completely not-php-way.
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
>
>
--
С уважением,
Виктор
