Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37150
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain cschneid.com from 195.226.6.51 cause and error)
Message-ID: <480B6E7A.8040803@cschneid.com>
Date: Sun, 20 Apr 2008 18:25:30 +0200
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Markus Fischer <markus@fischer.name>
CC: internals@lists.php.net
References: <46ccd1ab0804170742g142ed562t4f03339da549a820@mail.gmail.com> <1208466868.4430.10.camel@localhost>  <1208478266.5763.14.camel@pena> <1208500782.4430.14.camel@localhost> <D3575E90-4ED9-44E2-BF5B-100C9440A8A9@pooteeweet.org> <4809AC58.4070700@fischer.name>
In-Reply-To: <4809AC58.4070700@fischer.name>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
From: cschneid@cschneid.com (Christian Schneider)

Markus Fischer schrieb:
> $foo->bar( (int)$baz, (string)$sober, (bool)$result['column_checkbox'] );
> but this means he is really forced to think what he is really passing. 

I'm surprised that you find this desirable.

> It will not raise the overall code quality in a major way, but it helps 
> developers on both sides (devs of libraries, devs of using the 
> libraries) to ensure proper passing of varaibles.
> 
> It is optional. And it will likely be only used by 
> library/framework/component/whatever. But for them, I think, it's a win.

As explained before I consider a good framework to take work *off* of 
me, not make me think about details like whether 
$result['column_checkbox'] is 0, false or null to signify "option not 
checked". Why should I care? Typos in your parameters should be detected 
by testing (or something we've been thinking to implement as a PHP patch 
for a while but haven't gotten around yet: a warning about variables 
which are only used once).

I would even go one step further and compare this approach to the UAC in 
Windows Vista: It is annoying and at the same time teaches users to 
ignore warnings by simply "clicking Ok" (casting) because 99% of the 
time that's the right thing to do anyway.

A framework is written once but (hopefully) used any times. Why not make 
the framework robust enough to spare those details from its users? I'm 
tempted to call this approach unPHPonic (-:C

Ok, my horse is officially dead now ;-)
- Chris