Re: Re: Improving PHP's type system

I just noticed I originally missed "array" for #3. (The type is technically recursive, ie "type Jsonable = int|string|float|bool|null|array<Jsonable>", but that's another can of worms.) On Wed, Apr 20, 2016 at 9:54 PM, Jesse Schalken <me@jesseschalken.com> wrote: > 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üter <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 >> Decimal >> > 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 >> reliably >> > 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 >> throws >> > 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 >> not 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 those >> 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, by >> adding nullability, and by using interfaces where they make sense. >> >> Zeev >> > >