[RFC] [DISCUSSION] Scalar Pseudo-type

Am 26.12.2017 um 16:56 schrieb Sebastian Bergmann:

honestly *that* makes no sense for me with "float|int" you would have no need for dozens of aliases, in that case "numeric" when i expect some number but not a string and not a boolean return by a strpos() or similar functions also i have function which allows "int|array" where the internal logic loops the array internally but i don't want a random boolean or string there it's all about express accepted types as strict as possible in code to find errors early and in strict_types mode even the caller which needs to be fixed in the stack-trace

On Tuesday, December 26, 2017 9:56:21 AM CST Sebastian Bergmann wrote:

If I may, I think the argument has always been that 1) Foo & Bar makes total sense 2) int|float makes total sense 3) int & string is illogical so wouldn't matter anyway 4) Foo|Bar rarely makes sense but may sometimes, and its legality is an acceptable trade-off to get the first two. In previous discussions it always seemed that people fixated on case 4 and ignored the usefulness of cases 1 and 2. --Larry Garfield

On Tue, Dec 26, 2017 at 10:56 AM, Sebastian Bergmann <sebastian@php.net> wrote:

Would you feel differently if we combined union types with type aliasing? use Numeric = int | float; function foo(Numeric $bar) { ... } -Sara

Hi all, On 26.12.17 16:56, Sebastian Bergmann wrote:

I followed the discussion and found it interesting how strong the focus shifted about the discussion of the practical use cases. I would be for union types or scalars in ab instant, but I never had reason to scan our code-base and figure what would make really sense. Mind you this is a private codebase (Laravel based, as can be seen by some of the class names) but one where we tend to be very explicit about documenting everything, thus I knew I could just go ahead and extract the type hints using the '|' character and get back a pretty complete picture: $ grep -r '@param' *|grep \| | awk '{ print $4 }'|sort -u Attachment[]|Collection Attachment[]|null Builder|null Channel|Post|int|null Channel|int|null ClientInterface|null Client|int|null Collection|Attachment[] Collection|Channel[] Collection|Comment[] Collection|JsonapiModel[] Collection|Model[] Collection|Post[] DateTime|Carbon|string|null Dispatcher|null EloquentCollection|JsonapiModel[] Exception|null Group|Group[]|Client|Client[]|Channel|Channel[]|null Group|int|null JsonapiModel|null Model|int|null Post[]|null Post|int|null Profile|int|null ResponseInterface|null Throwable|null User|int|null \ArrayAccess|array|JsonapiModel[]|null array|false array|null int[]|int int|int[] int|null mixed|null null|LoggerInterface null|Model null|Model[]|Collection null|string string[]|Expression[] string|int string|null This is extracted from a codebase with ~400 files and ~43k LOC (incl. comments). I'm not saying anything like this is relevant codebase, but it's a project whose code quality I know well and I know the reason for every piece there. Since the discussion focuses on scalars here and ignoring all the nullables (they're auto-documented that way via PhpStorm) as well as ignoring the pseudo array-type hints, this leaves us really with only: - array|false Only 1 occurrence, used for crafting a remote HTTP call which has an interface which accepts either an array or false 🤷‍♀️ - string|int Only 1 occurrence, used for error codes which may come in either flavor, send back via HTTP somewhere I was surprised how less of a use we would really have for a) `scalar` itself and b) scalar unions. OTOH, typed array hints seem to be very useful as are class based union types. Although if one looks closely, it's clear this isn't a "union" problem, but rather an emulation due to the absence of Generics, e.g. Attachment[]|Collection Is clearly a replacement for something like Collection<Attachment> I hope I didn't distract to much from the discussion but though I throw in some data from an actual application. I'm sure there are much better OSS projects out there which could be used for such analysis. thanks, - Markus

On 12/26/2017 5:20 PM, Alexander Lisachenko wrote:

This is what I would like to see but making the primitives objects without too much BC is a complicated thing to achieve. Auto-boxing could be a solution. However, we would need many new things and new things are in general not well received in the PHP world if they replace other things.