From: Adam Jon Richardson [mailto:adamj...@gmail.com]
> I don't think it's fair to say that casting is too forgiving OR
> that current sentiment is settling around behavior similar to the
> internal zend_parse_parameters. This is a complex issue, and there
> are many core developers who have been focusing on other things
> besides this discussion. Their silence likely does not demonstrate
> sentiment of approval for anything at this point. This particular
> subject has much history on the PHP mailing list, and the opinions
> are far ranging. More importantly, this general subject has much
> history in all of the programming languages that are dynamically
> typed.
Sorry, you misunderstood. What I meant was *not* that core developers had
bought into this (whether that will happen is unknown.) I meant that the
discussion in this thread among the most active participants appeared to shift
hard this direction as soon as it was proposed (can't remember who by.) Taken
in the context of everything else it was a good foundation that solved a number
of problems all at once.
> Let's look at the examples you gave:
>
> (function(int){})('1'); // no error, function gets (int)1
> (function(int){})('123xyz'); // E_NOTICE, function gets (int)123
> (function(int){})('xyz'); // E_WARNING, function gets (int)0
>
> I'm wondering where you would be getting the values '123xyz' and 'xyz' from
> at runtime...
It doesn't so much matter where it comes from or why. The spec has to define
how such inputs are handled (the behavior can't be undefined). E_NOTICE and
E_WARNING matches a behavior that we know has already been considered
acceptable in the core (I.E. this is the behavior of substr()).
> Joe Armstrong, creator of the dynamically typed Erlang language,
> advocates performing checks on the datatypes at the points in the
> application that receive input, but not within the internal functions.
> It's an interesting view, and he seems to have had success building
> robust, stable software using this approach.
I tend to agree, but this sort of argument hasn't held much sway in the past on
the typing issue in PHP so in terms of designing a viable RFC that can pass a
vote I don't see that it matters much what we think here.
> Now, I'm not saying that this should be PHP's approach. I recently
> presented the idea of having a scalar type (with aliases) because
> this could identify problems the first time a PHP file is parsed
> rather than at runtime. However, I do bring up Joe Armstrong's
> approach to temper the belief that casting or something less is
> "too forgiving."
At least for me, script inputs are far less important than other stuff; for
example, generating good errors after a refactoring mistake. Allowing
everything to pass through without errors solves the documentation issue, but
basically nothing else.
> I very much enjoyed seeing someone as skilled as Anthony crank out
> a quick proof-of-concept (I'd still be sifting through Zend's
> internals trying to get out of my Objective-C mode of thinking.)
Yes, huge thanks for Anthony's contributions here.
> I just hope that we look at all options (including doing nothing),
> consider the research already done on dynamic type systems, and look
> to examples in other programming languages that can give us insights
> into what works well and what doesn't.
>
> Adam
Agreed. I've been advocating the collection and organization of information
from prior discussions for a while. If there is good stuff to learn from
discussions in similar languages we should look over that too. The primary
barrier I see here is time. Looking over all this will take a lot of work.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
