From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On Behalf Of Jesse Schalken Sent: Wednesday, April 20, 2016 4:42 PM To: Zeev Suraski <z...@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 <z...@zend.com<mailto:z...@zend.com>> wrote: On 20 באפר׳ 2016, at 14:54, Jesse Schalken <m...@jesseschalken.com<mailto:m...@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, 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 depends on whether you want to handle the details inside the SQLValue class or inside the function 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 to look at things. PHP has never been about purism, and we’re not going to start now. Instead of adjusting to how PHP models scalars, or moving to another language (both very valid options) – you 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 does it buy you?
