>
> And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
>
If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.
Your suggestion has a future compatibility problem. The introduction of new
type casting methods (like __toInt or like __castTo) is an open
possibility. In such a case, if those keywords are nothing but aliases for
"scalar", then there will be no way to choose which type casting method
should be chosen.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 Adam Jon Richardson <[email protected]>
> PHP currently allows users to provide type hints for functions and methods,
> although the type hints are currently limited to objects and arrays:
> http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking
>
> Restricting the type hinting to arrays and objects makes sense, as PHP's
> type juggling (similar in many ways to JavaScript's), a core feature of the
> language, performs automatic conversions between scalars as determined by
> context:
> http://php.net/manual/en/language.types.type-juggling.php
>
> 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.
>
> For example, the function below could have an object or array passed as the
> first argument, even though the expectation is a scalar:
>
> function foo($arg){
> // $arg is supposed to be a scalar and will be used as an int
> }
>
> *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
> }
>
> Now, the aliases wouldn't buy any more precision in terms of PHP's parser
> expectations. Your function/method parameters can only expect objects,
> arrays, or scalars. However, the aliases would allow developers to better
> communicate intentions AND provide more information for IDE's and static
> analyses tools. And, again, the use of the scalar hint and its aliases
> would preclude sending objects and arrays to functions expecting otherwise.
>
> I realize this subject is heated, and people's patience has worn thin. I'm
> just hoping to toss out this idea I've had for some time while all of the
> concerns on both sides are still fresh in my head.
>
> Thanks for reading :)
>
> Adam
>