On Tue, Jul 15, 2014 at 2:19 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
>
>
>
> 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
>
sorry, not neccessary the best place for my reply, I just had to type that
out seeing the dozens of mails from the last couple of days.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
