Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83258
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <032701d04b8a$bc7b9490$3572bdb0$@php.net>
References: <CAEYWF=7-mZRgDdu4eVZ8LCVD18e3dHJS2BAMQkSW9ajVdc6waA@mail.gmail.com>
	<032701d04b8a$bc7b9490$3572bdb0$@php.net>
Date: Thu, 19 Feb 2015 21:33:41 -0500
Message-ID: <CAEYWF=4xeRddyRH0Yf3aK6O6e3aA_p-2LKU+7Ag+EUTTe3+iJA@mail.gmail.com>
To: francois@php.net
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3c9667d2cb7050f7be13d
Subject: Re: [PHP-DEV] Nightmares on type hints, annotations, and aop...
From: bishop@php.net (Bishop Bettini)

--001a11c3c9667d2cb7050f7be13d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> >> THING 1: Hints are just is_* wrappers
> >
> > Wrong. Only *strict* types are.
> >
> >> THING 2: Hints are truthy callables
> >>
> >> function my_mixed($m) {
> >>     return (null =3D=3D=3D $m || is_string($m));
> >> }
> >> function f(is_scalar $s, is_int $i, my_mixed $m) {};
> >
> > Not sure I understand 'truthy callables'. Your example is a definition
> of 'strict-only' union types. It's a planned feature.
>

In my nightmare, users mobbed me after class, angry that scalar type hints
were confusing.  They couldn't believe I would test them on it.  I tired
calming them by describing weak- vs. strict- typing.  I implored the
benefit of aligning internal and external types.  I referenced The Dragon
Book.

The more I talked, the angrier the users became... and the more desperate I
became to find something that worked.

I scribbled on the white board of my dream:

function my_mixed($m) {
     return (null =3D=3D=3D $m || is_string($m));
}
function f(is_scalar $s, is_int $i, my_mixed $m) {
    printf('%s! %d, or %s', $s, $i, $m ?: '');
}

And in a moment, the torrent quieted.  They got this.  The hints aren't
keywords.  The "hints" are functions.  Functions like is_int or
is_resource.  Or user-defined functions.  The engine passes each formal
parameter's "function hint" the value of the corresponding actual
parameter. If the function returns false, the "hint" is violated and the
script crashes E_RECOVERABLE.

Anyway, I have contemplated my dream these last couple of days.  I'm sure
the tension of it reflects the heat of this debate, and the timing reflects
Andrea's departure.  The syntax my mind invented is, maybe, odd.  But I
think the syntax reflects something important about scalar type hints: they
must be intuitive to users.  It's true some of the is_* functions have
warts.  But users have grown up with them.  I've used them for nearly 13
years.  Users understand the semantics of is_*.  Maybe scalar type hints
should leverage that understanding.

I wonder if in trying to erase some of the coercion oddities, to align
internal and external types, and to formally codify the weak and strong
type rules that we're straying from the necessary intent: providing the
user benefit in a timely manner.

Sincerely,
bishop

PS: The fantasy syntax my dream invented can be emulated:

function hint_int($i) { return is_int($i) ? $i : throw new
InvalidArgumentException(); }

function add($a, $b) { $a =3D hint_int($a); $b =3D hint_int($b); return $a =
+
$b; }

On Wed, Feb 18, 2015 at 9:54 AM, Fran=C3=A7ois Laupretre <francois@php.net>
wrote:

> Hi Bishop,
>
> > De : bishop.bettini@gmail.com [mailto:bishop.bettini@gmail.com] De la
> part de Bishop Bettini
> >
> > THING 1: Hints are just is_* wrappers
>
> Wrong. Only *strict* types are.
>
> > THING 2: Hints are truthy callables
> >
> > function my_mixed($m) {
> >     return (null =3D=3D=3D $m || is_string($m));
> > }
> > function f(is_scalar $s, is_int $i, my_mixed $m) {};
>
> Not sure I understand 'truthy callables'. Your example is a definition of
> 'strict-only' union types. It's a planned feature.
>
> > THING 3: Pre- and post- blocks to define contracts, establish formal jo=
in
> > points, with or without hints from above
>
> Contracts are fine but cannot completely replace type hints. I initially
> followed this road but reverted to thinking that both tools have their us=
e.
> Contracts can implement performance-intensive checks but, because of this=
,
> cannot be executed in production. Type hints are performance-constrained
> but always executed. Another benefit of type hints is that PHP does not
> provide a consistent set of 'weak' is_xxx() functions yet. Checking for a=
n
> integer in PHP, for instance, when you're ready to accept 31, 31.0, or
> '31', is relatively complex and unintuitive, while 'int $arg'  is readabl=
e.
> If is_int() did a intuitive 'PHP way' check, contracts would be an
> alternative, but it is too counter-intuitive as it exists now. And BC mak=
es
> changing is_xxx() behavior impossible, of course.
>
> > I had to get these off my chest. Forgive me their implementation
> ignorance.
> > I am yet tired and uncaffeinated.
>
> No problem. Every goodwill is welcome.
>
> > To the void I commit their bodies...
>
> Sorry, my english is too poor for that. Can you explain?
>
> Regards
>
> Fran=C3=A7ois
>

--001a11c3c9667d2cb7050f7be13d--