Re: 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. 4. I have a function that returns the first key in an array (or throws an exception if empty). It returns int|string. 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). 6. I have a set of functions which operates on numbers. They accept int|float. 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). 8. Nullability is nothing but a special case of union type with T|null. If you need more examples, search some PHP codebases for PHPDoc blocks with union types with a regex, like "@(param|var)\s*(\$\w+\s*)?\w+\|". On Wed, Apr 20, 2016 at 7:46 PM, Johannes Schlüter <johannes@schlueters.de> wrote: > On Wed, 2016-04-20 at 17:57 +1000, Jesse Schalken wrote: > > > > With unions: > > > > function foo(Bar|string $b) { > > > > if (is_string($b)) { > > // ... > > } else { > > // I know $b is a Bar here. I don't need to check. :) > > } > > } > > I' still missing a real-life use case for this. There's no operation I > can come up with which works with an object or string. > > Unions between object types should be handled via interface. > > The only relevant union types I found till now are > > array | Traversable > array | Countable > > and eventually > > array | Offset[Get|Set] > > The last one is a bit critical due to the fact that arrays are value > types, whereas objects are reference types so > > function ($a) { > $a[] = 42; > } > > behaves notably differently between objects and arrays. So that case > might need some thinking. For the others instead of a generic union type > I'd prefer a special array-solution. > > johannes >