Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101388
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.87 cause and error)
Reply-To: internals@lists.php.net
To: Andreas Hennings <andreas@dqxtech.net>, Levi Morrison <levim@php.net>
Cc: Michael Kliewe <info@phpgangsta.de>,
 PHP internals <internals@lists.php.net>
References: <CAO7eTqNQ5T7=9pYC_q35ETnBDzNwEeSjvuvvv_uy3+LmEjcovw@mail.gmail.com>
 <a3f0e7dd-0afe-b44e-80ba-489e0f2b6ddd@gmail.com>
 <3a8054fd-b99f-771f-1f6c-29cf198acdeb@phpgangsta.de>
 <CAH0Uv3GRaZN4KW93ZyZautS2jQj-puvYEMNWKBPyzYV=15WBgg@mail.gmail.com>
 <CAH0Uv3F1cm8qaYxU6DwN6A+yFTkbExDmPOqhaMCW1sdH0Pg1nA@mail.gmail.com>
 <CAH0Uv3GDKzuyTX6viSmPNJtSspvVWPaekyavv4rnpNNu8Lovcw@mail.gmail.com>
 <CAFMT4NrxYDGox5gBVpfsqx=0+jp1pwZ21Ph96194ExnGru-iFQ@mail.gmail.com>
 <CAH0Uv3HXsV-Br2Co3G7EO9Hb_vnTfYF1XjZK-ZeL4n+tpRbU5w@mail.gmail.com>
 <CAFMT4NrDzu6F9eB3rf3ikj5=fg9vHDCQ2GONmVk+M9_q435GFA@mail.gmail.com>
 <CAH0Uv3EQXwexjqMVsnmbS=RAa9OHbe2+=BnSTycmD4cFLbOEoA@mail.gmail.com>
Message-ID: <be4ef96a-7568-0979-40cb-d1eddc6f54e9@fleshgrinder.com>
Date: Tue, 19 Dec 2017 19:19:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CAH0Uv3EQXwexjqMVsnmbS=RAa9OHbe2+=BnSTycmD4cFLbOEoA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Mixed Typehint
From: php@fleshgrinder.com (Fleshgrinder)

On 12/19/2017 6:43 PM, Andreas Hennings wrote:
> The argument, which I support, is that "mixed" would allow to
> distinguish against cases of "developer forgot to add a type hint" or
> "no type hint due to legacy / BC reasons".
> Also, with a "mixed" type hint, you know it is not "void" (this is
> still the same argument).
> 

The developer forgot the type constraint if there is no type constraint in:

1. the code
2. the DocBlock

This is a simple rule that you can already adopt without any changes to
the language. The thing is that mixed is not required at all at the
moment PHP supports more sophisticated type constructs. As I said
earlier, pursue them, not this.

PS: It's interesting how people fail to see the power of union and
intersection. This is currently happening on the Kotlin side too.

A simple example for a union type was already given: `string|int`.
Although in this case I would argue that anything that is convertible to
a hash (e.g. `Hashable` as found in php-ds) and ensures an equivalence
relation (not partial like float) should be usable as a key in an
associative array. The introduction of dedicated types for this is
definitely required in the language. That being said, union types are
usually of interest if you are interacting with some library code that
you cannot change (e.g. add interfaces to an existing type). Of course,
one could argue that the introduction of dedicated interfaces in your
own codebase plus adapters is the way to go but this requires much more
effort than the in-place union declaration.

Discriminating unions would be much nicer but that is something a proper
enum impl should cover.

Intersection is a whole other beast that is actually more powerful than
the simple unions we know from PhpDoc. Consider the following example:

    interface Writer
    interface Reader
    interface Seekable
    interface AutoCloseable
    interface Closeable

We could now continue and provide ReadableWriter, SeekableWriter,
SeekableReadableWriter, ... but this already gets out of hand. An
intersection on the other hand allows you to define exactly the features
you require:

    fn f(Closeable & Seekable & Writer writer)

This can of course be provided with a generics impl which would probably
make the parsing impl simpler:

    fn f<T: Closeable + Seekable + Writer>(T writer)

-- 
Richard "Fleshgrinder" Fussenegger