Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] Mixed type

Posted by Gabriel Caruso 
Gabriel Caruso
[PHP-DEV] [RFC] Mixed type
June 30, 2018 07:00PM
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 M. Becker
[PHP-DEV] Re: [RFC] Mixed type
June 30, 2018 08:00PM
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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] Mixed type
June 30, 2018 10:10PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] [RFC] Mixed type
June 30, 2018 10:20PM
On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Paul Jones
Re: [PHP-DEV] [RFC] Mixed type
June 30, 2018 10:40PM
> On Jun 30, 2018, at 15:17, Sara Golemon <[email protected]> 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




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [RFC] Mixed type
June 30, 2018 10:40PM
On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon <[email protected]> wrote:

> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <[email protected]>
> 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
Stanislav Malyshev
Re: [PHP-DEV] [RFC] Mixed type
June 30, 2018 11:20PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Gabriel Caruso
Re: [PHP-DEV] [RFC] Mixed type
July 01, 2018 06:30PM
>
> >> 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
Re: [PHP-DEV] [RFC] Mixed type
July 01, 2018 07:30PM
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 <[email protected]> wrote:
> On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon <[email protected]> wrote:
>
>> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <[email protected]>
>> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi Morrison
Re: [PHP-DEV] [RFC] Mixed type
July 01, 2018 11:50PM
On Sun, Jul 1, 2018 at 11:27 AM Rasmus Schultz <[email protected]> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login