Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=GrLoIbRhBZxrHCfyUfaQl+ehqn+iq2+J23Bu/2zv7tBK8tUDUE7aXDgK/kDRCRX2EZ
         seYE2xa4UrhfyxoV1YS0qpeK06KIzILINZNZ6/mqayl2RWzq82ubMhMotlKZW8HwSaEX
         XtIfcAiJsjpIo5wGc60Aw09kw+sHSyDv1l7vo=
MIME-Version: 1.0
In-Reply-To: <AANLkTimiKbBOi3ehj_ZujTjt12us-+FsacMvNqeOUCd0@mail.gmail.com>
References: <AANLkTim7sNwZWyo8dQz-o6S=Tta-OGYqnDM0cDJX3A49@mail.gmail.com>
	<1281478269.6608.292.camel@guybrush>
	<alpine.DEB.2.00.1008102325440.29410@kossu.derickrethans.nl>
	<AANLkTikaMfPERRH8bKqBj1ajf8muBrnQK_Gv6SZcObzK@mail.gmail.com>
	<AANLkTi=OebDc73DMVCUj5RJnHzv_VS6gn0_uATxb32dr@mail.gmail.com>
	<4C61E5CA.5070604@sugarcrm.com>
	<AANLkTi=_hPcCJYoH1v-G1vdwY2PY1aLhfDJNKwDLsK9T@mail.gmail.com>
	<4C61F3EF.5030409@sugarcrm.com>
	<AANLkTiniS9zQMU6WubkqBOL40i3COnwpnMgTSWqXO2XJ@mail.gmail.com>
	<4C6241D1.6030909@sugarcrm.com>
	<AANLkTinXQGCEhKR5C3iugq4Rv=Ym=dd-9A_jUdJFy6yR@mail.gmail.com>
	<AANLkTi=Xf8SW7=bh_2qh9GB5Bbd=kB1cXJcyeoVGPjtk@mail.gmail.com>
	<AANLkTimiKbBOi3ehj_ZujTjt12us-+FsacMvNqeOUCd0@mail.gmail.com>
Date: Wed, 11 Aug 2010 22:28:05 +0200
Message-ID: <AANLkTikVv=2rzug9QUof-bLq8C=AuZaEu5nQfQMkc8iR@mail.gmail.com>
To: Josh Davis <phpwnd@gmail.com>
Cc: Alexey Zakhlestin <indeyets@gmail.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016369f9dde56faa4048d921687
Subject: Re: [PHP-DEV] Strict typing
From: g.rossolini@gmail.com (Guillaume Rossolini)

--0016369f9dde56faa4048d921687
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 11, 2010 at 9:29 PM, Josh Davis <phpwnd@gmail.com> wrote:
>
>
> If I'm using type checking as a sanity check then it doesn't work as
> soon as it accepts "1" for an int. The described "weak typehinting" is
> good if you're looking for a way to validate input. However, it does
> not work if you're trying to make sure that Stuff Is Going As
> Planned(tm). For example, consider a protected method
> getTheNextNTokens(int $n) which is part of some tokenizer or
> something. It is a protected method and you never write
> getTheNextNTokens("2") so if it ever receives something that is not an
> integer, it means that there's a subtle bug somewhere. In that case,
> "strict typehinting" buys you peace of mind.
>
>
Hi

Thank you for the use case, we need more of them.

However in this example, what kind of application wouldn't make this $n
parameter configurable (ini file, XML file, user preference from a database
etc.) at some point? Then you would be back to square one, meaning you would
have to cast your database output so that your strict API accepts the
natural evolution of your app. Or you would have to get rid of the strict
check and replace it with a userland checking and validation chain (which
you should do anyway), at which point you wouldn't need or want type
checking but you would be glad to have type casting. In PHP, every single
value potentially comes from a kind of stream (file, HTTP or otherwise),
there is no such thing as a fully internal configurable value that I can
think of. Or is there? If there is, why would it need type checking at all?

Type checking or type casting won't save you much trouble since, as you said
yourself, in both cases you need to properly validate any data before doing
anything funny. However, with type checking you don't get any actual benefit
that I can see, while with type casting you can do other things relying on
the cast to properly format some of your data for you. If you have a
validation chain, why do you need type checking? If you don't validate your
data, type checking won't help. It would give a false sense of security,
nothing more. In edge cases like you described, type checking leaves you
with a broken app (fatal error / white page), while with type casting you'd
have a kind of recoverable error that you could... recover from. In neither
case your users care what happens internally, so IMO they should not be
taken hostage of your design mistakes or your choice of libraries. And yes,
if your app fails a typecheck, it means it fails with a fatal error and your
users get frustrated.

One use case I can think of is during testing, but in this case you can
already do the same with a testing framework. Just declare the types in the
comments and have the framework use those, but don't let them stand in the
way the app actually works. Using strict type checks would be like hard
coding your debugging breakpoints, would it not?

Best regards,

--
Guillaume Rossolini

--0016369f9dde56faa4048d921687--