> > 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 <adamj...@gmail.com> > 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 >
