Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34604
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain cumulo.fi from 81.228.11.168 cause and error)
Organization: Cumulo Studio
To: internals@lists.php.net
Date: Tue, 8 Jan 2008 16:03:35 +0200
User-Agent: KMail/1.9.7
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200801081603.35826.tomi@cumulo.fi>
Subject: Re: [PHP-DEV] type hinting
From: tomi@cumulo.fi (Tomi Kaistila)

> I believe the cleanest solution that we could implement would be using
> the type casting with "Type" objects.
I experimented with this for a couple of months, a couple of weeks ago. In 
opinion, it does not work well. I am guessing developers at java also figured 
the same since they still also have primitive types. Aside from the mentioned 
performance cost, it results in ugly and clumsy code. Not to mention you need 
to cast the objects into primitive types if you wish to use the variables 
with PHP functions.

function random(Integer $max, Integer $min)
{
    $n = rand($min->getInteger(), $max->getInteger());
    return $n;
}

Implementing the __toString() method in the classes helps a little but not 
much.

And really, if you think about it, just adding support to scalar type hinting 
solves the hold issue, thus making this sort of solution pointless and a pit 
hole wasted energy and time.

> Is there any reason we can't at least add "scalar" and 
> "resource" (and possibly "object" for generic objects) to typehints?
This sounds like, at least, a partial victory to adding proper type hinting to 
PHP but in my mind it is not enough. I have counted that about a quarter of 
all type hints that I would make is about matching the argument's type to 
scalar. The rest are about separating specific scalars from each other. In 
most cases integer and boolean.

I would probably end up not using type hinting at all, just to save the users 
of my API from the confusion and just do the type checks myself inside my 
methods.

> Thinking about this, simply because we all know PHP __CAN__ type
> juggle, there is no need for any errors/warnings/notices on scalar
> types. It will be up to the API developer to make sure appropriate
> values are supplied (if necessary), so this reduces the type checking.
In other words, it is not "in the spirit of PHP" to enable strict type 
hinting. I can understand this argument, but I still disagree heavily with 
this approach.

1) It is not consistent with the way that Array and Object type hinting works. 
While you might make the argument that it is not an issue because you cannot 
implicitly cast those types, it does create an annoying (yet another) magic 
behavior thing in PHP that people need to learn and remember. If anything, it 
will confuse new users, which I believe a lot of people were concerned about. 

Essentially, if it is necessary (and most of the time it is) to validate the 
value beyond just the type, you might as well do the casting at the same time 
as you validate.

2) The reason people are asking for type hinting for scalars is specifically 
to move some of the responsibility from the API developer to the user of the 
API and it is not an unreasonable request. After all, if person A has a 
program that asks for user input, the best place for validation is not in the 
class that person B wrote. The values should be validated in the program that 
asked for the input. Since the validation is necessary, person A can easily 
cast the type of the input at the end of the process, before he passes it to 
the class.

E.g.

function validate($input)
{
    // validate the input
    // return false if it was not valid
    // otherwise return a properly cast value
}

$input = $_GET['var1'];
$input = validate($input)

if(! empty($input)) {
    doSomething($input);
}

This seems like a perfectly logical division of labor. The validator validates 
and casts and the library class acts on the proper input.

Tomi Kaistila
PHP Developer