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 <johan...@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
>
