Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71151
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.195 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <001301cf1227$6d082ab0$47188010$@tutteli.ch>
References: <CABDNdAGCH5i9-=4Ys1CXeNaGWGmX=mkTiq0b7BbUKtBPdQ9XVg@mail.gmail.com>
	<001301cf1227$6d082ab0$47188010$@tutteli.ch>
Date: Wed, 15 Jan 2014 15:09:45 -0500
Message-ID: <CABDNdAHZTcE09kS-r_XTGOE9Q5EjTsEQyvzd29q0_nUqnPRrfQ@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Introducing "Array Of" RFC
From: pjsturgeon@gmail.com (Philip Sturgeon)

On Wed, Jan 15, 2014 at 2:24 PM, Robert Stoll <php@tutteli.ch> wrote:
> Hey,
>
>> -----Original Message-----
>> From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
>> Sent: Wednesday, January 15, 2014 7:18 PM
>> To: internals@lists.php.net
>> Subject: [PHP-DEV] Introducing "Array Of" RFC
>>
>> Hey,
>>
>> This is my first RFC so give me a little leeway if I get things wrong.
>>
>> https://wiki.php.net/rfc/arrayof
>>
>> The implementation has been written by Joe Watkins, and I will be
>> handling the RFC process for him.
>>
>> It is aimed at PHP 5.6, and so far the release managers seem to be ok
>> with the idea of this potentially being merged after the alpha
>> release, so this should not be considered an issue.
>>
>> Everything is open for discussion, especially the current error
>> messages. They are not perfect, so let us know if you have better
>> ideas.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
> First of all, I really like the RFC, good idea, well done.
>
> But about some details. I am not sure if I got the implementation right (haven't done any code contributions so far, so
> I am not really familiar with the source code) but it seems that a check for NULL is implemented for the actual
> parameter which is perfectly fine (done for other type hints as well) but it also checks if all members of an array are
> not NULL and the check returns a failure if NULL is detected. I think that's wrong, NULL is a perfect valid entry in an
> array.
>
> Furthermore, what about type hints like the following ones:
> function foo(int[] $qualities, callable[] $callables){}
>
> Seems like they are not supported. But might be that I am totally wrong and did not understand the code
>

Ok, ignoring the int stuff as PHP doesn't generally do that. We don't
want to broach that topic here.

As for allowing null, this feature is currently intended as a
syntactic representation of:

foreach ($foos as $foo) {
    if (! $foo instanceof Face) {
        throw new Exception ('AAAGGGGGHHH!');
    }
}

You are suggesting:

foreach ($foos as $foo) {
    if (! is_null($foo) and ! $foo instanceof Face) {
        throw new Exception ('AAAGGGGGHHH!');
    }
}

How do people feel about that?