Re: Re: Why no type hints for built-in types?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>From: "Matthew Weier O'Phinney" <matthew@xxxxxxxxxx>

> * Terje Slettebø <tslettebo@xxxxxxxxxxxx>:
> > In PHP5, you can provide "type hints" for functions, like this:
> >
> > class Person {...}
> >
> > function f(Person $p)
> > {
> >   ...
> > }
> >
> > Since this is optional static typing for objects, why not make the same
> > capability available for all types, built-in types included?
> >
> > I come from a background with generally static and strong typing (C++,
> > Java), and having worked with PHP a couple of years, I've quite a few
times
> > got bitten by stupid bugs that could have been caught by static typing,
such
> > as passing an empty string - which gets converted to 0 in an arithmetic
> > context, when the function was supposed to receive a number, or some
such,
> > and no error is reported. These bugs can be hard to find.
>
> This is where the === and !== comparison operators can come in handy, as
> they compare not only the values but the types. I often need to do this
> when checking for zeroes.

Hm, good point. However, this essentially means you have to do "manually"
what the compiler could have done. For example:

function f($a,$b,$c)
{
  assert("is_int(\$a)");
  assert("is_string(\$b)");
  assert("is_array(\$c)");

  // Actual function content here
}

At one time, I actually started to do this, but in the end, I found it
cluttered more than it helped; all those extra lines for each parameter:
clearly, the language worked against me on this. On the other hand, had I
been able to do this:

function f(int $a,string $b,array $c)
{
  // Actual function content here
}

then it would have been just fine. It also works as documentation,
specifying what the function expects (and might also specify what it
returns).

> > This has been suggested in a few Q & A's at Zend, such as this one:
> > http://www.zend.com/expert_qa/qas.php?id=104&single=1
> >
> > <snip>
> >
> > I don't find this answer satisfactory. Yes, PHP has loose/weak typing,
but
> > at any one time, a value or a variable has a distinct type. In the
example
> > in the quote above, you'd have to ensure that the value you pass is of
the
> > right type.
>
> I can recognize that this answer would not be satisfactory for someone
> with a background in traditional application architecture. However, PHP
> has been developed from the beginning as a programming language for the
> web. Since the nature of web requests is to transfer all values as
> strings, PHP needs to be able to compare items of different types -- '0'
> needs to evaluate to the same thing as 0. This may not be optimal for
> many applications, but for most web applications to which PHP is
> applied, it is considered a *feature*.

Yes, and I'm not against the dynamic/loose typing of PHP. However, as
mentioned in the other reply to Rasmus Lerdorf, there may be areas in your
application where the types are well-defined (not from GET/POST), and where
this might help. Even with GET/POST requests, it's often recommended to
"sanitize"/check these before using the values, and in this process, you
might fix the types (you can't very well check a a value you don't know the
expected type for).

> > This would also open the door to overloading, although it seems from the
> > replies from Andi and Zeev in the Zend forums that neither optional
static
> > typing, nor overloading is considered at this time, and likely not in
the
> > future, either. :/
>
> PHP already supports overloading as you're accustomed to it -- the
> syntax is different, and PHP refers to the practice as "variable-lentgh
> argument lists". You use func_num_args(), func_get_args(), and
> func_get_arg() to accomplish it:
>
> function someOverloadedFun()
> {
>     $numargs = func_num_args();
>     $args    = func_get_args();
>     if (0 == $numargs) {
>         return "ERROR!";
>     }
>     if (1 == $numargs) {
>         if (is_string($args[0])) {
>             return "Received string: $args[0]";
>         } elseif (is_object($args[0])) {
>             return "Received object!";
>         }
>     } elseif ((2 == $numargs)) {
>         return "Received arg0 == $args[0] and arg1 == $args[1]";
>     }
>     // etc.
> }
>
> Yes, this is more cumbersome than providing hints

Indeed, and it means all the selection have to be done in _one_ function.
Sure, varargs can give you some kind of overloading, but as with using
assert and is_* above, to check for incoming types, you essentially have to
"manually" provide the overloading (by checking argument number and types,
and dispatching appropriately), and then the alternative of using
differently named functions really look more appealing...

Besides, this makes the "switch function" a dependency hog: Every
"overloaded" function you add means you have to change it. If it's in a
third-party library, this may not be useful option.

> > There's a rather lively discussion about adding optional static typing
in
> > Python (http://www.artima.com/weblogs/viewpost.jsp?thread=85551), and
unless
> > it has already been, maybe it's time for us to consider it for PHP, as
well.
> > The current static type checking in PHP5 is something rather half-baked,
> > only covering user-defined types.
>
> I can definitely see a use for this -- but, again, PHP has been designed
> with loose typing as a *feature*. While type hinting may be a nice
> additional feature, I have my doubts as to the necessity or overhead it
> would incur.

I certainly know that a number of bugs I've encountered could have been
found with type hints for built-in types, so I think it would be useful. The
question, of course, is whether most PHP developers don't think so. Also, we
don't have any experience with it in PHP.

Thanks for your replies.

Regards,

Terje

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux