On Tue, Jul 15, 2014 at 2:50 PM, Alain Williams <addw@phcomp.co.uk> wrote:
> On Tue, Jul 15, 2014 at 02:19:46PM +0200, Ferenc Kovacs wrote:
>
> > But php doesn't care, because one of it's distinguished features is that
> it
> > can coerce between scalar types.
>
> Yes: and you will still be able to do that. No one will take that away, so
> continue to use that where it is appropriate.
>
you can't optionally introduce strict typing to php, as the two of them
can't co-exists.
nobody forces you to not use a language with strict typing if you want
that, but I don't think that it would worth changing the php type system at
this point.
>
> > 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.
>
> All input from a form needs to be validated before use; failure to do that
> is,
> unfortunately, common and leads to issues. If this helps remind people to
> do so
> then it can only be good.
>
the value needs to be validated, nobody argues that.
but enforcing the types where they are otherwise interchangeable doesn't
really provide any additional protection as far as I'm concerned.
it would only introduce mandatory boilerplate code where you cast your
integers to float or strings to int so that some function deep down in the
execution graph doesn't blow up before doing any sort of proper value
validation.
>
> The first listed here is ' Improper input validation':
>
>
> http://www.softwaretestinghelp.com/top-25-common-programming-bugs-every-tester-should-know/
as I mentioned above, nobody argues that input validation (and escaping
output in a context sensitive manner) is a must.
(btw. if you are interested in the topic I would suggest checkout out the
OWASP project and the top10 list especially)
>
>
> > 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.
>
> They will have it blow up when it first runs, fix the bug (add a cast or
> something) and move on. I think that it is an insult to PHP coders to
> assume
> that they will not be able to cope.
we had smaller BC breaks delaying the adoption of a new version with years.
as I said in my previous email, we can talk about it, but it is unlikely to
happen.
> They will scratch their heads the first time
> that it happens to them, google/... & learn.
>
yeah, and they
>
> The benefit of this is fewer issues in libraries. It may also help by
> catching
> user/coder errors earlier and so make their life easier.
>
it is already possible with the current status (just needs more boilerplate
code in the library), and it will be much more easier with the proposed
casting typehints.
as you are probably aware the typehint proposed in this rfc will also error
out when the casting would cause data loss.
>
> There is trade off bet
>
>
yeah, I just think that the gain(I don't see any) over the currently
proposed RFC doesn't worth the cost (which I consider huge).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu