Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85197
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: <CAGAGxbaFJ5anL6vr8RYn7=teFsqMSQJYs=pMXACeiaxzzj4vRw@mail.gmail.com>
References: <CAAyV7nEtdFSdPMieK0EvdO+moCqDw7KH59=Lr3+pA10rn=isoQ@mail.gmail.com>
	<CAB6YZuzrokpubXKKOzeM5tH=n2K6WPfX+YDwyKb4tByg33G7zw@mail.gmail.com>
	<CACwt+JdBDN95uN8csq5UaELozj3P4wbswhaYxvZ2hqh5JjALLw@mail.gmail.com>
	<CAB6YZuzkxWWq7ZA29TZVDsX7zBaEMvUGU7MC0gyuZHyZMNpqMQ@mail.gmail.com>
	<CALuY8tg_-AS9KYV-tKEBnrgbotszh_rZkfGg0dBAjLATpWRoSg@mail.gmail.com>
	<CAB6YZuy9dVaNvKiai8UExigQTt8tjC=FwK_XeOqmofpATgfDPQ@mail.gmail.com>
	<CALuY8tgw1rC+9jw1szQAAk0t7GjByPaM_JSVwzF-fqr0nUXV0w@mail.gmail.com>
	<CAB6YZuxvWX7u-iyBVOArfVOqbcVLiVoPCGjFRtDW9OkVKubbqw@mail.gmail.com>
	<CAGAGxbaFJ5anL6vr8RYn7=teFsqMSQJYs=pMXACeiaxzzj4vRw@mail.gmail.com>
Date: Wed, 18 Mar 2015 16:36:58 +0100
Message-ID: <CAEPJdu=WcNC-U8pr6L0ap2a9We29G7HETWwbGRyAhER68Z=bfg@mail.gmail.com>
To: Chris Wright <cw@daverandom.com>
Cc: =?UTF-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>, 
	Nikita Nefedov <inefedor@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1b8f08da7dc051191da39
Subject: Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
From: kontakt@beberlei.de (Benjamin Eberlei)

--001a11c1b8f08da7dc051191da39
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 18, 2015 at 4:28 PM, Chris Wright <cw@daverandom.com> wrote:

> On 18 March 2015 at 13:12, Pavel Kou=C5=99il <pajousek@gmail.com> wrote:
>
> > On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov <inefedor@gmail.com>
> > wrote:
> > > On 18 Mar 2015 15:52, "Pavel Kou=C5=99il" <pajousek@gmail.com> wrote:
> > >>
> > >> Hello,
> > >>
> > >> I made that conclusion because in the first example, the library kin=
da
> > >> forces strict mode rules on the caller, even if he doesn't want to u=
se
> > >> strict mode - this makes the interoperability of the two modes
> > >> problematic.
> > >
> > > This is incorrect, library force itself to use right types, not you. =
I
> > don't
> > > see any problems here. The only thing that for sure lacks in PHP and
> that
> > > would make STH better is callable signature types.
> > >
> >
> > Well, it forces you to do that, basically. And also forces you to
> > "care" about the mode of library, adding mental overhead. Look more
> > closesly at the first example - does the error in that case make sense
> > to you (from purely user's point of view)? When you call
> > a(function(int $b) {return $b * 2; }) - should you really be required
> > to check the context within the a() is declared?
> >
>
> You don't need to check the declaration context of a(). Either the librar=
y
> is definitely passing an integer and your code will work, or it isn't
> definitely passing an integer, maybe it's a float, so you shouldn't decla=
re
> the parameter type at all - it isn't a typed parameter. This is simply a
> matter of RTFM in the library docs (and if there are no docs or the docs
> are wrong then you have to go read the library code anyway just as you
> would today, so you haven't lost anything).
>
> Type declarations are a way to more completely describe the interface
> contract, they are *not* a replacement/shorthand for casts. If the desire=
d
> behaviour for your callback should be to accept anything and treat it as =
an
> integer for the computation, then your code should be written to describe
> that intent, i.e:
>
> a(function($b) {return ((int)$b) * 2; })
>
> This code both describes the behaviour of a() and the programmer's intend=
ed
> behaviour for the callback. Using a type declaration as a means to force =
a
> cast hides both of these - a reader would assume the callback is always
> called with an integer.
>
>
> >
> > >> Also, the other possible outcome of the scenario (respecting the mod=
e
> > >> of the place where the callback is declared), is IMHO problematic as
> > >> well, because it does not respect the strict mode of the place where
> > >> it is called, making it inconsistent with how the dual mode RFC work=
s
> > >> in general.
> > >
> > > It doesn't matter where the callback or function was declared, it onl=
y
> > > matters where it was called. It pretty much is consistent.
> >
> > This was just a comment about how it would be (also) wrong to solve it
> > the other way around.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

there is even a better argument for this, say you can add a callback to
your franework to register actions and it has to be:

function (Request $request, Response $response) {
}

This is the "public interface" of the callback so to speak. If you add
something different, you get a catchable fatal error, because you use that
library wrong, right now in PHP 5.*.

I don't see how strict mode enabled in a library, forcing you to define the
right signature for scalars is problematic from any POV. Granted you can
even just omit the scalar type hints completely and it would work.

--001a11c1b8f08da7dc051191da39--