Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85198
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
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 18:07:39 +0100
Message-ID: <CAMyk_AbSDDq7udufxoWSR8Ajsp=-m_e+fUcPQzh+v7ow0=R2mg@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=f46d04451a8f181926051193201d
Subject: Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
From: linepogl@gmail.com (Lazare Inepologlou)

--f46d04451a8f181926051193201d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-03-18 16:28 GMT+01:00 Chris Wright <cw@daverandom.com>:

> 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.
>
>
Yet, this code has a major flaw: the type of $b cannot be statically
inferred.

No matter how "strict" the new mode is, it can only catch errors at
runtime. This is usually too late. Having the ability to find error at
design time is priceless. For me, this is the primary reason I am using
type hints.



Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel




>
> >
> > >> 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
> >
> >
>

--f46d04451a8f181926051193201d--