Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44690
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Message-ID: <5A834C9A-6D1B-49B7-88E6-FF047B084AB6@pooteeweet.org>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sat, 4 Jul 2009 08:20:34 +0200
Subject: weak and strict type checking RFC
From: mls@pooteeweet.org (Lukas Kahwe Smith)

Hi,

Last evening I put together a quick proposal for a weak and strict =20
checking approach, since I felt that things were being concluded a bit =20=

prematurely. More importantly I detailed the issues I see with a pure =20=

strict type checking only approach.

I am publishing it a bit prematurely imho, but its not without merit =20
at this stage either and since I will be busy playing frisbee all =20
weekend, I thought I get it out there for people to comment right now:
http://wiki.php.net/rfc/typecheckingstrictandweak

As Paul insisted that my initial proposal did not sufficiently high =20
light the fact that there are other proposals, I moved my original =20
proposal to the above location so that we can have a disambiguation =20
page that lists all the various related proposals:
http://wiki.php.net/rfc/typechecking

Most of that is in there has been said/proposed on the list, so I am =20
just pasting the key section on why I think strict checking is =20
dangerous:
Strict type checking does have the advantage that subtle bugs will be =20=

noticed more quickly and that function/method signatures will become =20
yet more self documenting and therefore more expressive. Also doing =20
these type checks based on the signature also means less code and =20
better performance over having to hand code the validation
Proponents of only providing strict type checking say that for the =20
most part variables are defined with the proper type unless they come =20=

from an outside source, which usually requires validation anyways, =20
which is a perfect opportunity to type cast.

That is to define a variable that contains a boolean, developer will =20
probably do =93$is_foo =3D true=94 and not =93$is_foo =3D 0=94. While =
this may be =20
true, it does means that developers using such strict type checking =20
API's now require that users understand data types, which currently =20
beginning developers do not necessarily need to.

Furthermore quite often developers need to parse content out of =20
strings and pass this to other methods. With strict type checking one =20=

is now forced to explicitly type cast. While its certainly doable, its =20=

also additional work that needs to be done while writing the code =20
(=93$foo_int =3D (int)substr($bar, 3, 10)=94). Then again some might =
argue =20
that this makes the code clearer.

It also means that users of such strict typed API's will tend to =20
simply cast and due to laziness (PHP is used for rapid development =20
after all) might forgo validating first if the content is really what =20=

they expected. Without type checking the burden would be with the =20
developer providing the API. Since its usually expected that an API is =20=

fairly often, it seems illogic to move this burden to the API users. =20
More over due to this, a new kind of bug will be introduced due to =20
over use of cast instead of hand coded parameter validation as is =20
currently necessary. This could lead to even higher bug rates.

As for outside sources needing validation. This is not always the case =20=

as most people do trust that the data returned from a database is in =20
the expected format, even though for most RDBMS it will always be =20
returned as string. Same applies to configuration files, which if =20
defined in something else than PHP code will most likely only return =20
strings, but who's values will usually not be validated.

regards
Lukas Kahwe Smith
mls@pooteeweet.org