On Thu, Nov 3, 2016 at 8:52 PM, David Lundgren wrote:
> On 11/3/16 2:58 PM, Levi Morrison wrote:
>>> I think it would be bad to remove these functions and force users to
>>> wrap arrays with ArrayIterator, just to manually iterate an array. After
>>> spending a little time looking through how thes
On 11/3/16 2:58 PM, Levi Morrison wrote:
>> I think it would be bad to remove these functions and force users to
>> wrap arrays with ArrayIterator, just to manually iterate an array. After
>> spending a little time looking through how these functions are being
>> used in frameworks and libraries, r
> I think it would be bad to remove these functions and force users to
> wrap arrays with ArrayIterator, just to manually iterate an array. After
> spending a little time looking through how these functions are being
> used in frameworks and libraries, removing them seems like it will cause
> more
Thank you everyone for your feedback.
Nikita's post about wrapping the array with an ArrayIterator provides
the best approach to allow an array or Traversable to be used. This will
also provide the greatest backwards compatible usage for those of us
writing user code that would need to be compatib
On 01/11/16 05:53, Yasuo Ohgaki wrote:
> On Tue, Nov 1, 2016 at 11:53 AM, David Lundgren
> wrote:
>> > What if we made ArrayIterator transparently wrap all array's?
> If you take a look at SPL array object code, you'll see why there are
> so many missing functions. It's just pain for me to write
Hi David and all,
On Tue, Nov 1, 2016 at 11:53 AM, David Lundgren wrote:
> What if we made ArrayIterator transparently wrap all array's?
If you take a look at SPL array object code, you'll see why there are
so many missing functions. It's just pain for me to write new method
even with simple one
Hi Larry,
On Tue, Nov 1, 2016 at 6:49 AM, Larry Garfield wrote:
> Might it make sense then to have
>
> first(iterable)
> first_key(iterable)
> array_last(array)
> array_last_key(array)
array_ prefix is required for all new array functions, IMHO.
I don't have strong opinion for iter_ prefix for
On 10/31/16 4:49 PM, Larry Garfield wrote:
> If we're concerned about pw0ning the "first" function name, perhaps it's
> time to start a new prefix:
>
> iter_first(iterable)
> iter_first_key(iterable)
> array_last(array)
> array_last_key(array)
>
> Which gives a natural place to start putting iter
On 10/31/2016 01:07 PM, Levi Morrison wrote:
On Mon, Oct 31, 2016 at 11:57 AM, Levi Morrison wrote:
On Mon, Oct 31, 2016 at 11:27 AM, Larry Garfield wrote:
Question: Now that we have "iterable" as a type, should we be adding more
array-specific functions or should such operations be designed,
On 31.10.2016 at 18:27m Larry Garfield wrote:
> On 10/31/2016 11:26 AM, Alice Wonder wrote:
>
>> On 10/30/2016 10:19 AM, Rowan Collins wrote:
>>
>>> - deprecate reset(), end(), each(), and key()
>>> - introduce array_first(), array_last(), array_first_key() and
>>> array_last_key()
>>> - document
On Mon, Oct 31, 2016 at 11:57 AM, Levi Morrison wrote:
> On Mon, Oct 31, 2016 at 11:27 AM, Larry Garfield
> wrote:
>> On 10/31/2016 11:26 AM, Alice Wonder wrote:
>>>
>>> On 10/30/2016 10:19 AM, Rowan Collins wrote:
>>>
- deprecate reset(), end(), each(), and key()
- introduce arra
On Mon, Oct 31, 2016 at 11:27 AM, Larry Garfield wrote:
> On 10/31/2016 11:26 AM, Alice Wonder wrote:
>>
>> On 10/30/2016 10:19 AM, Rowan Collins wrote:
>>
>>>
>>> - deprecate reset(), end(), each(), and key()
>>> - introduce array_first(), array_last(), array_first_key() and
>>> array_last_key()
On 10/31/2016 11:26 AM, Alice Wonder wrote:
On 10/30/2016 10:19 AM, Rowan Collins wrote:
- deprecate reset(), end(), each(), and key()
- introduce array_first(), array_last(), array_first_key() and
array_last_key()
- document replacements for whatever other use cases we can find
examples of
On 10/30/2016 10:19 AM, Rowan Collins wrote:
- deprecate reset(), end(), each(), and key()
- introduce array_first(), array_last(), array_first_key() and
array_last_key()
- document replacements for whatever other use cases we can find
examples of
As a user I certainly like those names bette
On 30.10.2016 at 18:19, Rowan Collins wrote:
> On 30/10/2016 12:07, Fleshgrinder wrote:
>
>> I think it makes much more sense to deprecate all of them and introduce
>> new ones that work in the way we want them to for several reasons.
>> `end()` and `reset()` would have to continue working as they
Hi Nikita,
Nikita Popov wrote:
On Fri, Oct 28, 2016 at 2:43 PM, Levi Morrison wrote:
I can't seem to recall specifics anymore but I do believe some people
would greatly prefer to remove the internal array pointer for
iteration and deprecate these functions. Maybe someone else can
remember mor
Hi all,
On Mon, Oct 31, 2016 at 4:08 AM, Fleshgrinder wrote:
> On 10/30/2016 4:08 PM, Rasmus Schultz wrote:
>> But either way, I think I'm changing my mind about this one.
>>
>> And if the these functions support only arrays, then also the names
>> should probably be array_first() and array_last(
On 10/31/2016 12:25 AM, Yasuo Ohgaki wrote:
> It depends. Defining specific functions for a task could be bad design
> also. We do design basic functions with flags usually, too.
>
I know that we have lots of them but they almost always end up in hard
to read and understand I-can-do-everything fu
Hi, Fleshgrinder
On Mon, Oct 31, 2016 at 8:10 AM, Fleshgrinder wrote:
> On 10/30/2016 11:59 PM, Yasuo Ohgaki wrote:
>> There should be delete option. It's more useful if there is this option.
>>
>> mixed array_first(array $arr [,bool $get_key = FALSE [, bool
>> $remove_entry=FALSE]]);
>> mixed a
On 30/10/2016 23:10, Fleshgrinder wrote:
/** Get and remove the first element from the array. */
function array_take_first(array $array);
/** Get and remove the last element from the array. */
function array_take_last(array $array);
These two already exist; they're called array_shift() and a
On 10/30/2016 11:59 PM, Yasuo Ohgaki wrote:
> There should be delete option. It's more useful if there is this option.
>
> mixed array_first(array $arr [,bool $get_key = FALSE [, bool
> $remove_entry=FALSE]]);
> mixed array_last(array $arr [,bool $get_key = FALSE [, bool
> $remove_entry=FALSE]]);
On 10/30/2016 4:08 PM, Rasmus Schultz wrote:
> But either way, I think I'm changing my mind about this one.
>
> And if the these functions support only arrays, then also the names
> should probably be array_first() and array_last() for consistency with
> other array-only functions.
>
> Perhaps be
On 30/10/2016 12:07, Fleshgrinder wrote:
I think it makes much more sense to deprecate all of them and introduce
new ones that work in the way we want them to for several reasons.
`end()` and `reset()` would have to continue working as they do until
the next major release since people who use the
On 30/10/2016 04:31, Pierre Joye wrote:
I also think it is a good thing to clean up the ways to work with
arrays or iterable but we have to be very careful how we do it. I am
not sure an actual deprecation is a good thing in 7.x without breaking
any kind of tests out there. Indeed it will not bre
On Sun, Oct 30, 2016 at 10:31 AM, Levi Morrison wrote:
> On Sun, Oct 30, 2016 at 7:30 AM, Yasuo Ohgaki wrote:
>> On Sun, Oct 30, 2016 at 8:24 PM, Rasmus Schultz wrote:
>>> I'd like to just remind you of the fact that some
>>> of these functions, reset() and end() in particular, are often used
>>
On Sun, Oct 30, 2016 at 7:30 AM, Yasuo Ohgaki wrote:
> On Sun, Oct 30, 2016 at 8:24 PM, Rasmus Schultz wrote:
>> I'd like to just remind you of the fact that some
>> of these functions, reset() and end() in particular, are often used
>> not because someone cares about moving the internal pointer,
> What I am concerned with is the opt-out case of this functionality. What
> if I do not want that somebody misuses an unbuffered result set in such
> a way: selecting 1,000 records just to throw 998 away
In my opinion, that's a completely hypothetical use-case.
If I fetched 1000 records, most li
On Sun, Oct 30, 2016 at 8:24 PM, Rasmus Schultz wrote:
> I'd like to just remind you of the fact that some
> of these functions, reset() and end() in particular, are often used
> not because someone cares about moving the internal pointer, but as a
> means of getting the first/last items of an arr
On 10/30/2016 1:59 PM, Rasmus Schultz wrote:
> I think you misunderstand.
>
> I'm only suggesting that implementing first/last explicitly as an
> optimization be optional.
>
> If you call first() or last() on a traversable that doesn't implement
> this interface, it will simply traverse the first
On Sun, Oct 30, 2016 at 1:48 PM, Alice Wonder wrote:
> On 10/30/2016 05:31 AM, Rasmus Schultz wrote:
>
>> On second thought, I agree with that - changing reset() and end()
>> doesn't make sense, because people know them and expect them to work
>> in a certain way. Likely a lot of people would act
I think you misunderstand.
I'm only suggesting that implementing first/last explicitly as an
optimization be optional.
If you call first() or last() on a traversable that doesn't implement
this interface, it will simply traverse the first item or traverse to
the end.
In other words, it'll always
On 10/30/2016 05:31 AM, Rasmus Schultz wrote:
On second thought, I agree with that - changing reset() and end()
doesn't make sense, because people know them and expect them to work
in a certain way. Likely a lot of people would actually continue to
use them with intermediary variables the way the
On 10/30/2016 1:31 PM, Rasmus Schultz wrote:
> On second thought, I agree with that - changing reset() and end()
> doesn't make sense, because people know them and expect them to work
> in a certain way. Likely a lot of people would actually continue to
> use them with intermediary variables the
On second thought, I agree with that - changing reset() and end()
doesn't make sense, because people know them and expect them to work
in a certain way. Likely a lot of people would actually continue to
use them with intermediary variables the way they do today. Better to
introduce a new pair of fu
On 10/30/2016 12:45 PM, Nikita Popov wrote:
> On Sun, Oct 30, 2016 at 12:24 PM, Rasmus Schultz wrote:
>
>> With regards to deprecating array-functions that operate on the
>> internal pointer - I'd like to just remind you of the fact that some
>> of these functions, reset() and end() in particular
On Sun, Oct 30, 2016 at 12:24 PM, Rasmus Schultz wrote:
> With regards to deprecating array-functions that operate on the
> internal pointer - I'd like to just remind you of the fact that some
> of these functions, reset() and end() in particular, are often used
> not because someone cares about
With regards to deprecating array-functions that operate on the
internal pointer - I'd like to just remind you of the fact that some
of these functions, reset() and end() in particular, are often used
not because someone cares about moving the internal pointer, but as a
means of getting the first/l
> I also think it is a good thing to clean up the ways to work with
> arrays or iterable but we have to be very careful how we do it. I am
> not sure an actual deprecation is a good thing in 7.x without breaking
> any kind of tests out there. Indeed it will not break code but it is
> rather bad to
hi Nikita,
On Sun, Oct 30, 2016 at 3:06 AM, Nikita Popov wrote:
> On Fri, Oct 28, 2016 at 2:43 PM, Levi Morrison wrote:
>
>> On Wed, Oct 26, 2016 at 7:42 AM, David Lundgren
>> wrote:
>> > Greetings,
>> >
>> > As suggested by several reviewers of a PR[1] I recently submitted, I'd
>> > like to ge
On Fri, Oct 28, 2016 at 2:43 PM, Levi Morrison wrote:
> On Wed, Oct 26, 2016 at 7:42 AM, David Lundgren
> wrote:
> > Greetings,
> >
> > As suggested by several reviewers of a PR[1] I recently submitted, I'd
> > like to get feedback on letting custom Iterators be used in the current,
> > next, re
On Wed, Oct 26, 2016 at 7:42 AM, David Lundgren wrote:
> Greetings,
>
> As suggested by several reviewers of a PR[1] I recently submitted, I'd
> like to get feedback on letting custom Iterators be used in the current,
> next, reset, and key functions. If this is something to move forward
> with, I
Greetings,
As suggested by several reviewers of a PR[1] I recently submitted, I'd
like to get feedback on letting custom Iterators be used in the current,
next, reset, and key functions. If this is something to move forward
with, I'll need some help with the RFC process.
Recent experiences trying
42 matches
Mail list logo
