On Thu, Mar 8, 2012 at 6:08 PM, John Crenshaw <johncrens...@priacta.com>wrote:
>
> > Well, if your type hints gets more forgiving, than it's the same that was
> > proposed by this function a((int) $arg) {} And in this case hints have no
> > meaning at all - it's just other syntax to do the conversion that now
> looks
> > like this function a($arg) { $arg = (int)$arg; }
> >
>
> That's black and white thinking. Casting is obviously too forgiving (a
> cast literally accepts ANYTHING), and there were specific problems
> identified with that syntax that have absolutely nothing to do with whether
> you can juggle parameter types.
>
> Current sentiment seems to be settling around behavior similar to the
> internal zend_parse_parameters, which is to say:
> (function(int){})('1'); // no error
> (function(int){})('123xyz'); // E_NOTICE, function gets (int)1
> (function(int){})('xyz'); // E_WARNING, function gets (int)0
>
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.
One can find similar discussions regarding Ruby, Python, and general
discussions of type:
http://www.codecommit.com/blog/ruby/adding-type-checking-to-ruby
http://stackoverflow.com/questions/734368/type-checking-of-arguments-python
http://journal.stuffwithstuff.com/2010/08/31/type-checking-a-dynamic-language/
And, while there are some dynamically typed languages that allow optional
types, they don't provide much help here, either:
- Clojure allows type hints, but they're just for performance reasons.
http://clojure.org/java_interop
- Dart has optional types, but in Dart, everything is an object AND it's
types are unsound (i.e., let you get away with lots):
http://www.dartlang.org/articles/why-dart-types/
My point is that there are many beliefs about how to handle optional type
checks on function arguments in dynamic, weakly typed languages, and
there's not much precedent. That's not to say that nothing should be added
to PHP's capabilities. However, one constant question that emerges when
considering types in dynamic languages is what does it really buy you? The
value has to be significant, especially considering the lack of a compiler
that can ensure the correctness of a type before runtime. As Stas pointed
out in the thread for the Enun RFC (noting the importance of a compiler):
One note here: Java is a statically typed compiled language. PHP is not. So
> many arguments regarding type safety, etc. which are completely valid in
> regards to Java have no validity in regard to PHP. I understand that some
> people want to import some bits from strictly typed languages, imagining
> that this will provide them with benefits that statically typed languages
> have, namely compile-time safety checks, etc. This does not work as well in
> dynamic languages. Note for example that neither Ruby nor Python have
> enums, though you can do similar things there.
Let's look at the examples you gave:
(function(int){})('1'); // no error
(function(int){})('123xyz'); // E_NOTICE, function gets (int)1
(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 that you're passing off to a function expecting ints? If these
come from GPC's, then wouldn't an app pick up the issue BEFORE getting to
the point that they're being used as arguments through proper input
validation. And, if these come from a MySQL database, then wouldn't they
have been stored in a field that only stores some type of int (otherwise
one wouldn't be passing them to a function expecting ints.) And, if it
comes from a file, wouldn't the input be validated there, too, before
calling this function? Now, I'm not saying there are no examples, but they
would appear to be very limited in applications.
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. 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."
I am interested in adding some type of ability to PHP to catch issues at
parse time rather than runtime. And, 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.) 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
