Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34605
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain sambarrow.com from 205.234.132.11 cause and error)
To: Tomi Kaistila <tomi@cumulo.fi>
Cc: internals@lists.php.net
In-Reply-To: <200801081603.35826.tomi@cumulo.fi>
References: <200801081603.35826.tomi@cumulo.fi>
Content-Type: text/plain
Date: Tue, 08 Jan 2008 09:48:41 -0500
Message-ID: <1199803721.15292.269.camel@sbarrow-desktop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] type hinting
From: sam@sambarrow.com (Sam Barrow)

On Tue, 2008-01-08 at 16:03 +0200, Tomi Kaistila wrote:
> > 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.

But the syntax is longer ("$a = 5" vs "$a = new Integer(5)"), and if you
have a large application with hundreds of integers it starts to add up.
Performance is also much worse when using objects for every variable.

> 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.

Better than nothing.

> 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
>