>
> On May 26, 2010, at 5:20 PM, Zeev Suraski wrote:
>
> > At 23:44 26/05/2010, Davey Shafik wrote:
> >
> >> On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
> >>
> >> > At 21:12 26/05/2010, Pierre Joye wrote:
> >> >> As PHP's type system is seen as a big plus,
> >> >> I have to say that many users consider it as a plus in the
> >> >> implementation of a given method function or method. But the same
> >> >> users ask to have something more strict for the methods signature. I
> >> >> think it is a valid request and somehow makes sense too.
> >> >
> >> > I think that the proposed auto-converting type hints answer this request
> >> > quite well...
> >> >
> >> > Zeev
> >>
> >> Do you propose to have a warning when the types are a mis-match, similar
> >> to the
> >> array->scalar conversion example from Gustavo? (strtoupper(array('ABC')))
> >>
> >> If you have a warning or notice, that warns of potential loss of data
> >> accuracy, then
> >> I think I'd be OK with auto-converting.
> >
> > Yep - that's exactly the idea.
> >
> >> Having said that, all other type hints are strict, throwing a catchable
> >> fatal error consistency
> >> for what is essentially the same syntax, is more important IMO.
> >
> > In my opinion it's really a matter of whether the value makes sense in its
> > context or not. Much like a function that requires an object of type X
> > will accept an object of type Y if Y extends from X - because Y is a kind
> > of X, "42" is a kind of an int. It's true that no conversion is made in
> > the former case, but still - across 99.9% of PHP, "42", 42 and 42.0 are the
> > same thing.
> >
> >> Would it be possible to support two syntaxes:
> >>
> >> function foo( (int) $bar) { } // auto-cast to int
> >> function foo(int $bar) { } // require int
> >
> > I would advise against it - IMHO having both strict and auto-converting
> > type hints means having all of the issues of strict typing, and making that
> > worse by having similar confusing syntaxes on top of it... In general I
> > think there should be an exceptionally good reason to add core language
> > syntax. Auto-converting type hints would cater for the vast majority of
> > real world use cases. While I'm sure we can come up with situations where
> > you'd want a strict type check, for those few cases - you could simply use
> > is_int() - no need to add a language-level support for it.
> >
> > Zeev
>
> You could just as easily say to do:
>
> function foo($bar) {
> $bar = (int) $bar;
> }
>
> as:
>
> function foo($bar) {
> if (!is_int($bar)) {
> // error
> }
> }
Except this would be treated as an error with "42" and 42.0, whereas the
currently suggested implementation would not.
If your functions need strict type enforcement (I refuse to call it
hinting when there is no leeway that hinting implies), then you would be
better coding it in and reporting back any failures to the caller so
they can deal with it.
This is also true for type hinting.
Neither options are must have features in my mind, although type hinting
(hinting at what is needed and accepting anything which is close enough)
would be a nice to have feature.
> Why bother with either if that's the case? Why not add support for something
> like:
>
> function foo($bar) {
> (int) &$bar;
> }
>
> to allow for in-place casting (instead of temp-var+assign) and make it a
> shortcut.
>
> I'm sorry, but your reasoning is silly IMO. Type checking or casting are both
> currently
> easy enough to do; the only value in the auto-casting is to inform the user
> of loss of
> precision when they write against it. Does that really need language-level
> support?
>
> It could just as easily be part of the docblock.
>
> - Davey
> --
> 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
