Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92536
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.175 as permitted sender)
MIME-Version: 1.0
Sender: jesseschalken@gmail.com
In-Reply-To: <BY2PR02MB298D646863DE50029C9FC55AC6D0@BY2PR02MB298.namprd02.prod.outlook.com>
References: <CAFMT4Nq+VdfYS+eKbdbmPr92-X1QYCE2eOtPGo6Zu1qgAOGkhA@mail.gmail.com>
	<CAFMT4Nq=QPN9fOMtKa7GDDkf-AECAXjN9WRtn84nUjtKK-zD7w@mail.gmail.com>
	<570E99AC.3090804@fleshgrinder.com>
	<CAFMT4Nq7JV=iv=_AKjez+B8JxZ+rucD4LkEJgHuUg15o7r2hMg@mail.gmail.com>
	<570EA5EB.8090501@fleshgrinder.com>
	<570EAB0D.6080706@gmail.com>
	<570EB67E.8010908@garfieldtech.com>
	<5B147E88-CC0A-4CBC-A49D-C7FE3BF557C0@zend.com>
	<6F.C3.12455.94C5F075@pb1.pair.com>
	<20160414094440.GF19347@phcomp.co.uk>
	<CAKSD0w6Gd7uN2L=d3VfnK-Mj+cwjpcGtCpjfD6iq+VMmJVxkhA@mail.gmail.com>
	<570FD94F.90703@fleshgrinder.com>
	<570FE8A9.4020809@gmail.com>
	<20.53.29891.17401175@pb1.pair.com>
	<CAF1yvAToWKqcj4-0xoTC_B9n2+DFLuNwKrf2Te3zNWwB7n5ziw@mail.gmail.com>
	<1461145606.7556.11.camel@kuechenschabe>
	<CAF1yvATYTn+tWYk12WeqysAWVRH7G+WCz5WwgMTAZgNq2BSJZg@mail.gmail.com>
	<BY2PR02MB298D646863DE50029C9FC55AC6D0@BY2PR02MB298.namprd02.prod.outlook.com>
Date: Wed, 20 Apr 2016 21:54:46 +1000
Message-ID: <CAF1yvAQaP34X9K1duM1rMWDDO=FbJYEb-yP2kE2q_k39NBq8qQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f8a5c9a9c690530e94282
Subject: Re: [PHP-DEV] Re: Improving PHP's type system
From: me@jesseschalken.com (Jesse Schalken)

--001a113f8a5c9a9c690530e94282
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If I had "scalar", "number" and ?T as types, the types I would need would
be:

   1. ?scalar|Decimal
   2. ?scalar|Decimal|Expr
   3. ?scalar|array
   4. int|string (I *want* int|string here. I know array keys are always
   int|string. A wider type is lies.)
   5. ?scalar (probably)
   6. number
   7. T|false
   8. ?T

5 out of 8 still need a union.

On Wed, Apr 20, 2016 at 9:01 PM, Zeev Suraski <zeev@zend.com> wrote:

>
>
> > -----Original Message-----
> > From: jesseschalken@gmail.com [mailto:jesseschalken@gmail.com] On
> > Behalf Of Jesse Schalken
> > Sent: Wednesday, April 20, 2016 1:12 PM
> > To: Johannes Schl=C3=BCter <johannes@schlueters.de>
> > Cc: Andrea Faulds <ajf@ajf.me>; PHP internals <internals@lists.php.net>
> > Subject: Re: [PHP-DEV] Re: Improving PHP's type system
> >
> >    1. I have a function that converts values to SQL which have SQL
> >    equivalents, including decimal values represented by a special Decim=
al
> >    class. It accepts int|string|bool|null|float|Decimal.
> >    2. I have a class Expr which represents an expression in SQL.
> >    Expressions can be composed of other expressions, and of literal
> values, so
> >    the constructors for Exprs accept
> int|string|bool|null|float|Decimal|Expr.
> >    3. I have a function that converts values to JSON that can be reliab=
ly
> >    converted back into their original. It accepts
> int|string|bool|null|float.
>
> In other words, they accepts scalars (or nullable scalars).  Introducing =
a
> scalar type would do the job.
>
> >    4. I have a function that returns the first key in an array (or thro=
ws
> >    an exception if empty). It returns int|string.
>
> I'd argue that here too, a scalar would be fine.  Worrying about a
> floating point here is not a very relevant worry.
>
> >    5. I have a function that returns a value for a key in an array, and
> >    removes the key. The type of the key is things that are valid array
> keys
> >    (int|string|bool|null IIRC).
>
> Scalar (or nullable scalar).
>
> >    6. I have a set of functions which operates on numbers. They accept
> >    int|float.
>
> Numeric (to also include strings that look like numbers when strict is no=
t
> on).
>
> >    7. All the PHP functions which say "returns ... or FALSE on failure"
> >    have their correct return type as T|false (where T is the return
> value on
> >    success) (or T|bool is "false" is not an allowed type).
>
> How many of those do we have?  As opposed to T|null?  I think most
> functions that return objects return null on failure, not false.  And tho=
se
> who don't can probably evolve to that approach.
>
> >    8. Nullability is nothing but a special case of union type with
> T|null.
>
> Academically that's true, but practically speaking, the general T1|T2 is
> almost always bogus while T|null subset makes a lot of sense.
>
> In reality, we can solve all the relevant use cases for union types by
> relatively minor tweaks (or rather additions) to our scalar type hints, b=
y
> adding nullability, and by using interfaces where they make sense.
>
> Zeev
>

--001a113f8a5c9a9c690530e94282--