On Mon, Jul 14, 2014 at 7:19 PM, Kristopher <kristopherwil...@gmail.com>
wrote:
> On Mon, Jul 14, 2014 at 1:14 PM, Alain Williams <a...@phcomp.co.uk> wrote:
>
> > On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
> > >
> > > On 14 Jul 2014, at 18:01, Alain Williams <a...@phcomp.co.uk> wrote:
> > >
> > > > But if you have:
> > > >
> > > > function foo(int $a) {
> > > > ...
> > > > $a = 3 / 2;
> > > > }
> > > >
> > > > What do you expect $a to contain ? I would suggest integer 1.
> > >
> >
> I would have expected 1 - since it appears, from the code, that $a should
> > only contain integers.
>
>
> What about the current type hinting we have, then?
>
> function foo(Bar $a) {
> $a = 3 / 2;
> }
>
> Perfectly OK. Why would we treat scalars any different?
>
this was asked and answered a dozen of times in the past, but let me repeat
once again:
php does support type juggling/coercion for scalar types, but not for
complex types.
introducing "strict" typehints for complex types was safe, as there are no
expectation from the users, if you expect an instance of Foo and you got a
Bar (which isn't a subclass of Foo) then you know that you screwed up.
(personally I think that the adding the support for array to the strict
typehints was a bad idea, but that is out of scope here.)
But people do have expectations about the scalar types in php, and they
used to not care about the exact types of a variable as long as it can be
coerced into the expected type.
If you think it over, probably 80-90%+ of all incoming data we are working
with coming from a source which delivers everything as a string (anything
coming from HTTP is a string, anything coming from the database which isn't
using a binary protocol arrives as string, anything coming from memcached
is a string, redis: same thing).
But php doesn't care, because one of it's distinguished features is that it
can coerce between scalar types.
If we introduce scalar type hints, people will use it, if they will use it,
people have to be aware that they can't pass numeric looking strings into
functions and expect them to work.
It will blow up with a fat E_RECOVERABLE_ERROR.
But this won't hold back the library authors from using it, which means
that the consumers of those libs has to start coding defensively, and make
sure that the variable holding the value 123 is an integer and not a float
or a string, because that will blow up something.
And we can argue whether or not it is a good thing that php has type
juggling, but we have that, and it is not likely to be changed(biggest BC
break ever), so introducing something which completelly negates that won't
likely to get support from the devs.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
