On Tue, Jan 30, 2018 at 12:13 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote: > > On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield <la...@garfieldtech.com> > > > > wrote: > > > Really, these functions would be useful only on arrays, period. To > allow > > > them > > > on anything else is just dangerous, and on other iterables there are > > > better, > > > more robust approaches (as discussed elsewhere in this thread). > > > > > > As you've demonstrated they're also quite compact and effective to do > in > > > user- > > > space, so unless there's a massive performance difference of moving > them > > > to C > > > they don't seem all that appropriate to add to the language directly. > > > > > > --Larry Garfield > > > > Didn't you personally raise the issue of hard dependencies doing this > sort > > of functionality creates? Implementable in userland or not, this is > pretty > > low level functionality. > > I don't recall doing so in this thread, but I most likely have on some > other > issue. It's the sort of comment that I would make. :-) > It was during the discussion on the Drupal list on adding runtime assertions, the Inspector class in general. Curiously, no one on that list raised the problem of allowing Inspector to traverse any Traversable. At the time Drupal was PHP 5.4 min, so no generators to consider, and I guess the other implications skipped everyone's mind. Personally I think that's fine, and doesn't need a language-level utility > function to wrap it any further. > > We'll just have to disagree then. After all, roughly half the array_* functions can be user implemented, as can roughly half the string functions (though how to do so is often cryptic to beginners). array_test might not be the best name. Anyone got alternatives other than the one in the abandoned RFC mentioned elsewhere in this thread (Not that that one is bad, but if this is the direction to go some input on what to actually call the thing would be nice.)?
