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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
