>From: "Richard Quadling" <[EMAIL PROTECTED]>
> On 12/09/06, Terje Slettebø <[EMAIL PROTECTED]> wrote:
> > function f(Something $value) /** @return SomethingElse */
> > {
> > // ...
> > }
>
> One of the good things about PHP is the loose typing (1.00 == 1 == "1"
> sort of thing as I understand it). This has been useful.
I'd say that's debatable. :) Yes, it can make it more convenient to handle
data coming from outside the script (such as forms), but it can also hide
bugs. While it can be argued that conversions between, say, arithmetic types
(int and floats) may be useful, allowing conversion from something like NULL
to empty string, integer 0, etc. (as PHP does) may be going a little over
board, as an uninitialised variable (such as a member variable) may not be
easily discovered.
It's interesting to note that Java (a newer language than C++) actually has
a stronger type system (at least in some respects) than C++: While C/C++
allows things like implicit conversion between int/float/pointer and bool (a
legacy from C), Java does not, and if you think about it, it makes sense to
disallow that, as boolean values are conceptually different from these.
> But one of the first things we are told about using PHP ITRW is to
> always validate user input and to make sure you only accept what you
> know to be valid data.
True, and at least with regard to function calls, with type hinting (as you
mention below), that testing is done for you, so you don't have to, leading
to less code and syntactic noise (and possibly better performance).
> We can already use type hinting for arrays and classes for parameters.
> Type hinting could be extended to all types for user functions.
I asked about this about 1 1/2 year ago (as well as the possibility of
function overloading - which _would_ be at least theoretically possible, now
that we have type hints), on this list, but got a very negative response to
that... So... I figured the PHP community wasn't ready for that, or didn't
think it fit the language. I still think type hints for fundamental types
could be a good idea, for catching errors early, such as passing NULL to a
function expecting string (as long as it avoids the usual implicit
conversion).
Anyway, with Sara Golemon's operator overloading extension, it's possible to
make your own Integer, Float, String, etc. types, and use them basically as
built-in types, making it possible to use them for type hints.
> Even
> the possibility of accepting multiple types for a single parameter
> could be used to support a mixed type.
One way to do that could be to create a user-defined "variant" type (or
"mixed" type, as you say), that may contain a specified number of types.
Yes, I know that in PHP, basically all variables are "variants", but with a
class, you may restrict it to just a few specific ones.
Likewise, it's possible to create type-checked tuple types (a sequence of
values, of specified types), and ditto arrays.
As it's mentioned in the user-contributed notes on autoloading, you may even
"abuse" the autoloader to implement "parametric types" (like templates in
C++). For example, if you write:
function f(Array_string $value)
{
}
The autoloader may "synthesise" the "Array_string" type, from a generic
typed array class, to produce a custom array type that enforces numerical
indexes and string values (the above is really short for "Array_int_string",
where "int" gives the key type, and "string" gives the value type).
Again, this may be useful for expressing intentions in code, as well as
runtime-enforced conditions.
> Recently we had a discussion about parameter overloading on methods.
> You can probably use __magic to produce the effect of parameter
> overloading.
I'm not sure what you mean by "parameter overloading". Do you mean function
overloading? Yes, you can "simulate" that, using e.g. a dispatch based on
func_get_args(), but it's rather inelegant, compared to real overloading.
Also, it's impossible to overload existing functions in the standard library
(if it was, you could provide your own count(), array_*-functions, etc. for
user-defined array types.
> Whilst casting the return type is easy to do, having the return type
> as part of the function declaration would be very useful for
> auto-documentors.
Not only that, but in my opinion the more important thing that you may
enforce a return type (forgetting to return a proper value from a function
could be caught this way).
> As for syntax, I would go with ...
>
> type function f(type $value)
Yes, that's _one_ possibility. Let's see it in "all its glory" (i.e. with a
lot of other qualifiers):
public abstract SomeClass function f(SomeOther $value)
Hm, maybe. Another alternative might be (closer to C/C++/Java syntax):
<qualifiers> function <return type> <function name>(<parameters>)
E.g.:
public abstract function Someclass f(SomeOther $value)
> It would be useful to also have VOID as a return type, but that may be
> open for discussion.
Yes, or perhaps more natural for PHP, "null".
> But mixed type returns (normal type -string/int/real/Boolean - for
> valid results AND Boolean False for failure) would need to be
> considered.
Perhaps something similar to current type hints could be used here, where
you may allow the specified type _or_ null (if you default the argument).
However, some kind of variant may be sufficient, here (i.e. no language
support for mixed result needed), such as a type (class) like
"Variant_SomeType_null", where you may check the resulting value (using
implicit conversion to string via __toString()) if it's null (or false, or
whatever).
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
