[RFC] Mixed type

6 years ago by Gabriel Caruso — view source

unread

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

6 years ago by Christoph M. Becker — view source

unread

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

6 years ago by Stanislav Malyshev — view source

unread

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

6 years ago by Sara Golemon — view source

unread

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

6 years ago by Paul Jones — view source

unread

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

6 years ago by Nikita Popov — view source

unread

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

6 years ago by Gabriel Caruso — view source

unread

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

6 years ago by Rasmus Schultz — view source

unread

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 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

6 years ago by Levi Morrison — view source

unread

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.

6 years ago by Stanislav Malyshev — view source

unread

Hi!

I would enjoy a 'mixed' typehint for exactly that reason; i.e., that I don't have to put it in a docblock.

I think it is exactly the opposite of what should be happening in the
language - putting things in the code which belong in the documentation,
so you don't have to write documentation. I don't think it is a good
direction.

Given this method ...
public foo(string $bar, int $baz) : void { ... }
... I don't need any docblock at all for the params.

You still do. You still need to describe what the parameters do and what
the function does.

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:

I think it's a misguided idea that the more type specifications the code
has the better is the code. "$dib" and "mixed $dib" say exactly the
same thing. That you do not limit what type it is. But instead of
placing it in proper place for explanatory things - namely, comments -
it places it in the code.

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.

It just means you moved some documentation into code. Which didn't make
it adequate - it's still an undocumented function - but made you feel
you don't need to document it now. I don't think it's a good thing.

--
Stas Malyshev
smalyshev@gmail.com

Thank you all

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.

Thanks,

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.