Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82633
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <F1EA749C-B5A5-4128-98FC-3293A9B60FED@ajf.me>
References: <8703B53E-2C4A-4AC6-95C4-D4F19C6D5221@ajf.me>
	<CABBJUpf=wKvGY9+xORRv6WVhCb5+LfRZXGYNasHFS=fz_mwaZQ@mail.gmail.com>
	<CABBJUpeceN1uDK870eV2=znC9f3eaxqYCmaEk0ErH2cbFxTNEw@mail.gmail.com>
	<CABBJUpdYnaR2nztPwFUdDAiAneRrAWzGo-36-DA9hqiBjEHXNA@mail.gmail.com>
	<54DAF884.7000508@lerdorf.com>
	<203e611c8e0b03568a868b8d931aec37@mail.gmail.com>
	<F79D6CDF-20DD-4E24-B2F4-F12637368242@ajf.me>
	<CAEPJdukxaE+Ln0aibs=57YDmyjU8OcneeUK7-5YEQ95L57hjOQ@mail.gmail.com>
	<F1EA749C-B5A5-4128-98FC-3293A9B60FED@ajf.me>
Date: Fri, 13 Feb 2015 19:00:27 +0100
Message-ID: <CAEPJdunnc2KVMDTdk0pbaigdbFQsdE4h4frHG9BwhjChKc5gdA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Zeev Suraski <zeev@zend.com>, Rasmus Lerdorf <rasmus@lerdorf.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01419d1cfbb9a3050efc02ed
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: kontakt@beberlei.de (Benjamin Eberlei)

--089e01419d1cfbb9a3050efc02ed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 13, 2015 at 5:59 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi,
>
> > On 13 Feb 2015, at 16:18, Benjamin Eberlei <kontakt@beberlei.de> wrote:
> >
> > Wait i almost forgot, it *does* have an effect on me, especially around
> callback handling:
> >
> > https://gist.github.com/schmittjoh/778e044deacc6f1fe516
> >
> > Essentially callbacks are evaluated in the mode they are called in, not
> in the one they are defined.
>
> This is correct, yes. This is only going to cause a problem, however, if:
>
> * You add type hints despite not knowing what types will be passed
> * You add type hints for the wrong types
>
> In both cases, you have only yourself to blame for your code not working.
> So, I really don=E2=80=99t think it=E2=80=99s an issue. If you don=E2=80=
=99t know what types will
> be passed, why did you add type hints? If you know what types will be
> passed and added incorrect type hints, why did you expect that to always
> work?
>
> There is of course a third case: the function=E2=80=99s documentation lie=
s and
> claims the function will call your callback with certain types, and
> actually passes different types. However, this is not a problem with the
> RFC, and is something that could happen anyway. At least with this RFC, y=
ou
> might discover the bug in the library more quickly due to getting an erro=
r.
>
> Anyhow, we could catch such errors prior to call-time by extending the
> callable typehint to take a parameter list, such that parameter type hint=
s
> can be checked (with the same rules as used by inheritance). This would
> solve your problem.
>

Yes, you are right, but think about the same problem in a changing code
base.

What if I pass the closure into a file that is now weak, and then this file
changes to strict.

You argue that hints are only responsible for a single file, but that is
not true. When changing a file to strict, I have to verify that no closures
are passed in that previously relied on weak type hints. Since there is no
interface for callbacks (dynamic invocation) this means reviewing all the
calling code as well.

The same applies to any form of inheritance, see this example:
https://gist.github.com/beberlei/6045bce658026cbdb6ab

The user typehints against a class in weak mode (Foo) and makes use of
that. Now depending which implementation is used (weak or strict) their
code suddenly fails.

Again this example is constructed and probably a bug on parts of the person
building inheritance3.php (class Baz), however you only see this when
calling index.php



>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

--089e01419d1cfbb9a3050efc02ed--