Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Mixed type »

[RFC] Mixed type

php.internals

Gabriel Caruso

8 years ago
Hello, internals Together with Michael Moravec, we’d like to announce that we are pretending to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) next Monday (02/07) and we’d like to ask you to take a look into the PR on GitHub (https://github.com/php/php-src/pull/2603) and let us know if there's something else to do before it. Thank you all
-- Gabriel Caruso

Christoph Becker

8 years ago
On 30.06.2018 at 18:57, Gabriel Caruso wrote:
> Together with Michael Moravec, we’d like to announce that we are pretending > to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) next > Monday (02/07) and we’d like to ask you to take a look into the PR on > GitHub (https://github.com/php/php-src/pull/2603) and let us know if > there's something else to do before it.
Thanks! A minor issue: the RFC mentions: | In some other languages like C/C++ void can also be used as a type | that accepts any type. This doesn't appear to be correct. Are you referring to void*?
-- Christoph M. Becker

Stas Malyshev

8 years ago
Hi!
> Together with Michael Moravec, we’d like to announce that we are pretending > to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) next > Monday (02/07) and we’d like to ask you to take a look into the PR on > GitHub (https://github.com/php/php-src/pull/2603) and let us know if > there's something else to do before it.
I think this is wrong. This "type" - which is not really a type, of course - does not add anything to the code, by definition - if you take it out, everything would be the same. Things like that belong in the documentation. Moreover, it makes the code harder to read, as the reader should make mental effort to discard this non-type every time it is mentioned, as it does not carry any information.
> In some other languages like C/C++ void can also be used as a type
that accepts any type. This is wrong. void is not used in C/C++ as type that accepts any type. Moreover, void is not type at all, it means the function it describes does not accept arguments or return values.
-- Stas Malyshev smalyshev@gmail.com

Sara Golemon

8 years ago
On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> Together with Michael Moravec, we’d like to announce that we are pretending >> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) next >> Monday (02/07) and we’d like to ask you to take a look into the PR on >> GitHub (https://github.com/php/php-src/pull/2603) and let us know if >> there's something else to do before it. > > I think this is wrong. This "type" - which is not really a type, of > course - does not add anything to the code, by definition - if you take > it out, everything would be the same. Things like that belong in the > documentation. Moreover, it makes the code harder to read, as the reader > should make mental effort to discard this non-type every time it is > mentioned, as it does not carry any information. >
I would say that, in a world without union or intersection types, it adds to the readability of the code by explicitly saying, "We accept more than one type here, and we know we accept more than one type here." This is distinct from, "We have no idea what type we accept here." That adds to readability, it doesn't detract. I preface that with a mention of union/intersection types because that seems to be the *actual* problem this RFC is attempting to cope with while lacking the tools to do it right. I'm not super excited about this RFC because, as you say, this information could be easily encoded into the docblock for the function/method. Zero impact to the syntax, same benefit for the programmer and their readability. (More benefit, really, as docblock standards *do* permit union/intersection types. So, complex types maybe? -Sara

Paul M Jones

8 years ago
> On Jun 30, 2018, at 15:17, Sara Golemon <pollita@php.net> wrote: > > I'm not super excited about this RFC because, as you say, this information could be easily encoded into the docblock for the function/method.
I would enjoy a 'mixed' typehint for exactly that reason; i.e., that I don't have to put it in a docblock. Given this method ... public foo(string $bar, int $baz) : void { ... } ... I don't need any docblock at all for the params. But given *this* method ... public foo(string $bar, int $baz, $dib) : void { ... } ... I find myself wanting (for completeness' sake) to add a docblock indicating the $dib typehint: /** * @param mixed $dib ... */ public foo(string $bar, int $baz, $dib) { ... } ... and *then* the docblock looks unusual to me, and I want to fill out all the rest of the params in the docblock. Yes, I'm aware that may be idiosyncratic. Even so, being able to do this ... public foo(string $bar, int $baz, mixed $dib) { ... } ... relieves that bit of docblock dissonance. If it does so for me, I bet it would do so for others.
-- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php

Nikita Popov

8 years ago
On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon <pollita@php.net> wrote:
> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <smalyshev@gmail.com> > wrote: > >> Together with Michael Moravec, we’d like to announce that we are > pretending > >> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) > next > >> Monday (02/07) and we’d like to ask you to take a look into the PR on > >> GitHub (https://github.com/php/php-src/pull/2603) and let us know if > >> there's something else to do before it. > > > > I think this is wrong. This "type" - which is not really a type, of > > course - does not add anything to the code, by definition - if you take > > it out, everything would be the same. Things like that belong in the > > documentation. Moreover, it makes the code harder to read, as the reader > > should make mental effort to discard this non-type every time it is > > mentioned, as it does not carry any information. > > > I would say that, in a world without union or intersection types, it > adds to the readability of the code by explicitly saying, "We accept > more than one type here, and we know we accept more than one type > here." This is distinct from, "We have no idea what type we accept > here." That adds to readability, it doesn't detract. > > I preface that with a mention of union/intersection types because that > seems to be the *actual* problem this RFC is attempting to cope with > while lacking the tools to do it right. I'm not super excited about > this RFC because, as you say, this information could be easily encoded > into the docblock for the function/method. Zero impact to the syntax, > same benefit for the programmer and their readability. (More benefit, > really, as docblock standards *do* permit union/intersection types. >
I'm basically with Sara here. Generally the feature has some merit, but I'm sure that given our current type-system, and in particular the lack of union types, this feature will be misused to annotate parameters that do *not* accept completely arbitrary values, but where "mixed" is the best approximation we have. For that reason I would prefer to defer this addition until proper union types are supported. In that case mixed would be a shortcut for the otherwise somewhat unwieldy type of ?(bool|int|float|string|array|object|resource) (modulo the non-existence of resource...) Nikita

Gabriel Caruso

8 years ago
> > >> Together with Michael Moravec, we’d like to announce that we are >> pretending >> >> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) >> next >> >> Monday (02/07) and we’d like to ask you to take a look into the PR on >> >> GitHub (https://github.com/php/php-src/pull/2603) and let us know if >> >> there's something else to do before it. >> > >> > I think this is wrong. This "type" - which is not really a type, of >> > course - does not add anything to the code, by definition - if you take >> > it out, everything would be the same. Things like that belong in the >> > documentation. Moreover, it makes the code harder to read, as the reader >> > should make mental effort to discard this non-type every time it is >> > mentioned, as it does not carry any information. >> > >> I would say that, in a world without union or intersection types, it >> adds to the readability of the code by explicitly saying, "We accept >> more than one type here, and we know we accept more than one type >> here." This is distinct from, "We have no idea what type we accept >> here." That adds to readability, it doesn't detract. >> >> I preface that with a mention of union/intersection types because that >> seems to be the *actual* problem this RFC is attempting to cope with >> while lacking the tools to do it right. I'm not super excited about >> this RFC because, as you say, this information could be easily encoded >> into the docblock for the function/method. Zero impact to the syntax, >> same benefit for the programmer and their readability. (More benefit, >> really, as docblock standards *do* permit union/intersection types. >> > > I'm basically with Sara here. Generally the feature has some merit, but > I'm sure that given our current type-system, and in particular the lack of > union types, this feature will be misused to annotate parameters that do > *not* accept completely arbitrary values, but where "mixed" is the best > approximation we have. For that reason I would prefer to defer this > addition until proper union types are supported. In that case mixed would > be a shortcut for the otherwise somewhat unwieldy type of > ?(bool|int|float|string|array|object|resource) (modulo the non-existence of > resource...) > > Nikita >
Hello Nikita, Sara, Stan I agree with you that mixed in our current type system would be missused by those that want to document more than one type. So, the best to do would be to wait for a `union type` system in PHP, and than merge this feature to really document that a function accepts anything? Thanks,
-- Gabriel Caruso

Rasmus Schultz

8 years ago
Nikita, I think we'll need the mixed type-hint in any case if we're to move ahead with generics? On Sat, Jun 30, 2018 at 10:30 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

Levi Morrison

8 years ago
On Sun, Jul 1, 2018 at 11:27 AM Rasmus Schultz <rasmus@mindplay.dk> wrote:
> I think we'll need the mixed type-hint in any case if we're to move > ahead with generics?
I think Rasmus is alluding to this: interface Iterator<KeyType = mixed, ValueType = mixed> { // rest of impl } So that we can make things generic but backwards compatible. Is that what you are referring to, Rasmus? ----- The name "mixed" has been in our manual for over a decade (possibly closer to 2 decades) so I am fine with adding it to the language even if I would prefer a different name for the semantic. I think the most common name in other languages for this type is "any", which sometimes excludes null, so "?any" is the same as "mixed". I prefer "?any" but would still vote in "mixed". If we are going to add it I would prefer that we: - Add a deprecation notice in 7.3 informing users that they need to change their name. - Create "mixed" or "?any" in 8.0. This is the responsible thing to do if we are going to add it. There is no functionality in 7.3 that will require it so there's no rush.