RE: [PHP-DEV] Re: Improving PHP's type system

From: jesseschalken@gmail.com [mailto:jesseschalken@gmail.com] On Behalf Of Jesse Schalken Sent: Wednesday, April 20, 2016 4:42 PM To: Zeev Suraski <zeev@zend.com> Cc: PHP internals <internals@lists.php.net> Subject: Re: [PHP-DEV] Re: Improving PHP's type system On Wed, Apr 20, 2016 at 10:55 PM, Zeev Suraski <zeev@zend.com<mailto:zeev@zend.com>> wrote: On 20 באפר׳ 2016, at 14:54, Jesse Schalken <me@jesseschalken.com<mailto:me@jesseschalken.com>> wrote: If I had "scalar", "number" and ?T as types, the types I would need would be: 1. ?scalar|Decimal What's decimal? I'm not aware we have that type. Apologies if I missed it that it was added. As I said: 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. Zeev> So just use a container class (SQLValue or whatnot) that can include a scalar or a Decimal, Zeev> and use this instead. It would probably result in a cleaner function body anyway. 1. ?scalar|Decimal|Expr What's Expr? Again I'm not aware that we have that type. As I said: 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. Zeev> Same as above. Another option of course is to handle the type checks inside – that Zeev> depends on whether you want to handle the details inside the SQLValue class or inside the function Zeev> that accepts it. 1. ?scalar|array Conduct this check in user code, you'd have to anyway. Not if I'm giving it straight to json_encode() I don't. Zeev> Why not let json_encode() do the type checking then? 1. int|string (I want int|string here. I know array keys are always int|string. A wider type is lies.) This is needlessly purist. For handling a meaningless con, we'd overcomplicate the language and provide a footgun(tm) for everyone. Not a good bargain. int|string is the correct type. If you're going to dismiss correctness as "needlessly purist" then I'm going to dismiss PHP as not intended for writing correct software. Zeev> Purism by definition – in all areas of life - insists it’s the one and only correct way Zeev> to look at things. PHP has never been about purism, and we’re not going to start now. Instead of Zeev> adjusting to how PHP models scalars, or moving to another language (both very valid options) – you Zeev> insist on saying PHP must change to be your way. 1. T|false You didn't answer my question on this one. substr() returns string|false file_get_contents() returns string|false fopen() returns resource|false strpos() returns int|false etc.. Without unions, the types of these functions cannot be denoted. Zeev> Why is it important to have a type that maps the return values of these functions? What Zeev> does it buy you?