Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37124
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
Cc: Felipe Pena <felipensp@gmail.com>,
 internals@lists.php.net
Message-ID: <D3575E90-4ED9-44E2-BF5B-100C9440A8A9@pooteeweet.org>
To: Lars Strojny <lars@strojny.net>
In-Reply-To: <1208500782.4430.14.camel@localhost>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Fri, 18 Apr 2008 09:03:51 +0200
References: <46ccd1ab0804170742g142ed562t4f03339da549a820@mail.gmail.com> <1208466868.4430.10.camel@localhost>  <1208478266.5763.14.camel@pena> <1208500782.4430.14.camel@localhost>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.142, required 6, AWL 0.04, RDNS_DYNAMIC 0.10)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
From: mls@pooteeweet.org (Lukas Kahwe Smith)

Hello All,

I just want to bring in a different perception on the proposed  
feature. I think people are very focused on what I call "library  
code". This is the kind of code that should in theory be worked on  
less, than the glue code that you write in every project to finish up  
the applications your customers have requested.

IMHO type hinting and more importantly strict type hinting is very  
focused with making the life of library developers easier. They can  
just easily discard anything that doesnt match their expectations  
100%. That this is not how PHP has traditionally worked has been  
mentioned quite often in this thread. But I want to direct peoples  
attention to the code that calls strictly typed libraries.

Suddenly I need to ensure that all my variables have the proper types.  
So what will people do? They will start forcing type juggeling  
manually before they call the library in question. Since this is the  
glue code, its the kind of code you have to write day in day out. So  
maybe an "(int)" here or there is not so much more code to type, but  
you can already see that code you safe on one end, you have to start  
adding on the other, the one which you write more often. More  
importantly, in some cases simple type juggeling with "(int)" will not  
be sufficient, you might have to do some minor checks etc. In the past  
library authors did this as part of the code that the strict type  
hinting camp is now hoping to remove. So again more code in my glue  
code.

Furthermore people over estimate the usefulness of automated errors.  
They tend to include very minimal context information. So when in the  
past people had to write out the parameter checking code manually,  
they had the opportunity to very easily add important context  
information to whatever error they raised. This will no longer be the  
case with strict type hinting. There it will be the responsibility for  
the caller to make sense of the error and know whatever context is  
relevant for this error condition.

I guess the reply I can expect from this mail is that I do not have to  
use it, that I do not have to use libraries that use strict type  
hinting or that good developers will pick and choose when to use  
strict type hinting. While this may be true, we do not live in a  
perfect world. So again I want to remind people that as we develop the  
language, we need to pick and choose what features come in that will  
ensure that PHP remains at least as productive has it has been in the  
past for its users.

As such I want to again bring up that a loose type hinting with types  
like "scalar" and "numeric" are much less risky, since they are a much  
wider filter. Its quite easy to figure out why a function that is  
documented to not operate on arrays to come back with an error when I  
pass it an array. However it will be a bit confusing to get an error  
when I pass '1' to a method that then comes back to complain I did not  
pass an integer.

regards,
Lukas