Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71174
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain apfelbox.net from 37.139.17.48 cause and error)
Date: Thu, 16 Jan 2014 11:38:35 +0100
To: Robert Stoll <php@tutteli.ch>
Cc: 'Philip Sturgeon' <pjsturgeon@gmail.com>, 'Marco Pivetta'
 <ocramius@gmail.com>, 'Kristopher' <kristopherwilson@gmail.com>, 
 internals@lists.php.net
Message-ID: <29D5E17DED4340E4AB756A336E0D3E80@apfelbox.net>
In-Reply-To: <004c01cf123d$35730870$a0591950$@tutteli.ch>
References: <CABDNdAGCH5i9-=4Ys1CXeNaGWGmX=mkTiq0b7BbUKtBPdQ9XVg@mail.gmail.com>
 <001301cf1227$6d082ab0$47188010$@tutteli.ch>
 <CABDNdAHZTcE09kS-r_XTGOE9Q5EjTsEQyvzd29q0_nUqnPRrfQ@mail.gmail.com>
 <CAF9U7z-qR-JnXmbuS-ok2NnB_QzecM1Z4MGhek77rktdSYmcmQ@mail.gmail.com>
 <CADyq6s+KqD4Sp00NcJKDAAxX+xWT4x1C3_D1zMVqZ1PRKf__9w@mail.gmail.com>
 <002d01cf1234$01e6dc60$05b49520$@tutteli.ch>
 <CABDNdAEAQyyLQXFw3tw8S9Rb=+9Z-k1K_geX6HG7x1reCoJ5Rw@mail.gmail.com>
 <004c01cf123d$35730870$a0591950$@tutteli.ch>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="52d7b6ab_140e0f76_e1d"
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC
From: hello@apfelbox.net (Jannik Zschiesche)

--52d7b6ab_140e0f76_e1d
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,


Am Mittwoch, 15. Januar 2014 um 23:00 schrieb Robert Stoll:

> Fair enough, the example with the English sentence makes pretty much sense from an average user's point of view and thus
> most PHP users would probably agree with you (don't take it wrong, I don't imply you are average or something similar). 
> However, this should not be a decision based on whether many people are preferring it this way or the other way round in
> my opinion, since the restriction is going to make it impossible to use it for the use cases where NULL is a valid
> entry. 
> So, we should ask ourselves, do we really want to exclude a whole bunch of valid use cases or should we decline the
> restriction and put more effort in providing alternatives for non-null -containing collections.
> 
> See, if we do not introduce the restriction and provide a non-null-containing collection then all use cases can be
> supported. That is the way to go IMO.
> Or do you have another idea how one can specify that the array can contain null?
> And please consider, if you should suggest "function foo(Foo[] $foo=null)" implies that $foo can also contain NULL then
> we have another vague concept in PHP which has a double meaning -> $foo can be NULL and entries in $foo can be NULL. But
> maybe one does not want to allow NULL for $foo but only for members of $foo.
> 
> 



if you pass an array which mixes both objects and null and you want to work on the objects, you still have to do the checks yourself:

function f (A[] $list)
{
    foreach ($list as $entry)
    {
        if (!is_null($entry))
        {
            $entry->doSth();
        }
    }
}


But in this case you could just omit the type hint and check it internally:

function f ($list)
{
    foreach ($list as $entry)
    {
        if (!is_null($entry) && ($entry instanceof A))
        {
            $entry->doSth();
        }
    }
}



The thought of this proposal is that the complete checking is done with just the type hint.
And allowing null would make this obsolete.

Also, you would then have the duplicated runtime impact:
you need to check the array twice:

1. check for null & A (type hint)
2. check for A

instead of just one. 



Cheers
Jannik 


--52d7b6ab_140e0f76_e1d--