Re: Re: Improving PHP's type system

On Wed, Apr 20, 2016 at 10:55 PM, Zeev Suraski <zeev@zend.com> wrote: > > On 20 באפר׳ 2016, at 14:54, 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 > > > 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. All of int|string|bool|null|float can be converted to SQL straightforwardly, however, MySQL has a distinct decimal type for exact decimal values, written like "8542.31" in SQL (to get write a float, you need "8542.31e0"). My class Decimal is used to represent a MySQL value of type decimal, so it can be passed without be lossily converted to/from float, and so it can be converted to the correct SQL. It is neither a float nor an integer. A distinct class is needed for it. > > 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. In both, a nullable scalar does the job. > > > 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. > > 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. > > 1. ?scalar (probably) > > Ok > > > 1. number > > Ok > > > 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. > 1. ?T > > Ok > > 5 out of 8 still need a union. > > > Actually, in my count only one of them does (#7) and it's probably > solvable (if it's even a thing), and in another, it makes no sense to use > types at all (#3) as you'd have to do these checks in userland anyway. All > others can be satisfied just fine with scalar, numeric and nullable types, > unless you're being needlessly purist - and we're not going to > overcomplicate the language for the sake of purism. > > Zeev >