Re: [RFC] Mixed Typehint
| From: | Andreas Hennings | Date: | Tue, 19 Dec 2017 11:37:43 +0000 |
| Subject: | Re: [RFC] Mixed Typehint | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-101381@lists.php.net to get a copy of this message | ||
Perhaps this is the same reason why we add "public" keyword, even
though a member is implicitly public by default.
On 19 December 2017 at 12:34, Andreas Hennings <andreas@dqxtech.net> wrote:
> I agree with Michael Kliewe.
> When looking at code, I want to distinguish between:
> - Developer forgot to add a type hint, or it was left out for legacy /
> BC reasons.
> - The function can really return various types, at least too many for
> any more specific type hint.
>
>
> On 19 December 2017 at 04:57, lists@rhsoft.net <lists@rhsoft.net> wrote:
>> no, mixed is used in phpdoc comments to say "no type specified at all" when a
>> param accepts anything and in case of "@return mixed" that it can return void, array,
>> int.....
>
> I think "mixed" should not include "void".
> A well-written method/function either has a return value or not. It it
> is type-hinted as "mixed", then we should expect it to have a return
> value.
>
> On 19 December 2017 at 08:06, Fleshgrinder <php@fleshgrinder.com> wrote:
>> What is really needed are
scalar, L
>> Ç1”’ÁkԞǴ݅¤Mnumber, union types, intersection
>> types, and all that together with generics.
>
> I would like to see those too, but they are not mutually exclusive
> with "mixed" and should rather be discussed separately.
>
>
>
> On 19 December 2017 at 11:01, Michael Kliewe <info@phpgangsta.de> wrote:
>> Am 19.12.2017 um 07:32 schrieb Stanislav Malyshev:
>>>
>>>> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
>>>> https://wiki.php.net/rfc/mixed-typehint
>>>>
>>>> The purpose of this RFC is to introduce "mixed" typehint on language
>>>> level
>>>> to be used
>>>> as a valid typehint. PHP currently forces users to not use any type in case
>>>> the
>>>> type is mixed/unclear. This makes code inconsistent and less explicit. With
>>> I'm not sure what's the point of it. "mixed" means "any
>>> type". Not
>>> writing a type means "any type". So why waste space and add something
>>> that contributes nothing when everybody is already using the current
>>> convention and the new one does not add anything at all?
>> A "mixed" type hint says that it's really "mixed", and the
>> developer who
>> wrote that code did not forget to add a type hint.
>> If you see a place where a type hint is missing, you don't know if it's
>> mixed, or the developer/you missed to write the correct type hint.
>>
>> That's the benefit I see. I would explicitly write "mixed" everywhere in
>> a fully type-hinted codebase, to eliminate this thought while reading:
>> Is it really mixed, or was this place overseen and it's not mixed, but
>> something else...
>> Because it's optional, nobody is hurt, but some people (like me) could
>> add this explicit information.
>>
>> Michael
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>