On Wed, Feb 29, 2012 at 09:01:05PM -0500, Adam Jon Richardson wrote:
> However, the lack of scalar hinting does limit the ability of a developer
> to declare his/her intentions for function/method parameters. A non-hinted
> parameter expecting a scalar could be sent an object or an array, breaking
> the expectations (and much of the time, the functionality) of the code.
> That is to say, there is a value in declaring what the parameter IS NOT,
> too.
+1
> *What if PHP added the hint scalar?* The example could be rewritten as:
>
> function foo(scalar $arg){
> // $arg is supposed to be a scalar and will be used as an int
> }
>
> The idea is that the failure to send a valid scalar argument to the
> function would result in the same feedback that currently occurs when array
> or object hints are not heeded. Now, the expectations for each
> function/method parameter can be explicitly declared (or, at least, more
> explicitly.)
> And, *what if PHP added the following aliases for the hint scalar*:
>
> - bool
> - int
> - float
> - string
>
> The function could then be rewritten as below:
>
> function foo(int $arg){
> // $arg is supposed to be a scalar and will be used as an int
> }
A nice compromise for a heated issue. This would also open the way to more
complete checking (as has been discussed) at some time in the future.
It would provide a better alternative to some of the ghastly pseudo comment
conventions that are currently used as means of documentations.
Programming is about communication of intent, not just with the computer
(compiler) but also with programmers who subsequently read the code.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
