Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97132
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c9rvYefG2RrjP15GRnGYwdYSZEs7rAc4Me_y=uajKM8mA@mail.gmail.com>
References: <CAOv67gtevNzxuBf270re+Jt8T7Wnb9hj3TLOGq2A7kemayWKJA@mail.gmail.com>
 <CAF+90c9rvYefG2RrjP15GRnGYwdYSZEs7rAc4Me_y=uajKM8mA@mail.gmail.com>
Date: Tue, 22 Nov 2016 22:56:47 +0100
Message-ID: <CAOv67gtbvh_xeWsChK9comFBhOC10CCwmrO==9pZQD+Y=kLo0g@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c1abb4a5fa8c40541ead991
Subject: Re: [PHP-DEV] [RFC] ArrayIterator improvements
From: netmo.php@gmail.com (Wes)

--94eb2c1abb4a5fa8c40541ead991
Content-Type: text/plain; charset=UTF-8

I have decided to go with that because

1- I'm a fan of using Exceptions (mostly) for exceptional error conditions;
between these two
public seekKey($key):void throws WhateverException;
public seekKey($key):bool;
I (by far) prefer the latter.

2- I think it would require a new type of SPL Exception, because none of
the existing makes sense to use here, in my opinion.

2016-11-22 21:43 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>:

> On Tue, Nov 22, 2016 at 6:47 PM, Wes <netmo.php@gmail.com> wrote:
>
>> Greetings again PHPeople,
>>
>> I wanted to avoid the discussion for the small improvements I was
>> proposing
>> thinking it would be acceptable to do so (
>> http://news.php.net/php.internals/97118) but apparently I was wrong
>> (sorry
>> for that), so here's the discussion thread!
>>
>> https://wiki.php.net/rfc/arrayiterator-improvements
>>
>> Again this is my first RFC, and I hope I'm doing nothing wrong this time
>> :P
>>
>> Thanks again,
>> Wes
>>
>> (and special thanks to Room11 for their feedback about the RFC process)
>>
>
> What's the reason for making seekKey() return a boolean? The existing
> seek() method throws an exception if the seek offset does not exist. It
> would make sense to me for seekKey() to throw an exception if the key does
> not exist, to keep things consistent.
>
> Nikita
>
>

--94eb2c1abb4a5fa8c40541ead991--