nikic/iter

Version 2.0

nikic opened this issue · 12 comments

nikic commented

I'd like to release version 2.0 with PHP version requirement bumped to 7.1 and added type hints.

Are there any other (breaking) changes that should be done now?

Not sure it is a BC break, but would it make sense to return static closures?

nikic commented

@staabm What would be the benefit? As this is a function library, we don't have a $this binding, so we're not holding onto unnecessary objects or causing GC issues. Is the idea to prevent an explicit rebinding?

Hmm idea was preventing a $this binding, but as you said.... in this case there isnt one.

isIterable could be removed now that we depends on PHP >= 7.1 that has is_iterable.

My 2 cents would be a way to enable better composition of iter funcs. It can only be so good since we are using php, but it would be nice if we could have something like:

$items = compose(
    filter(function($v) { return $v % 2 == 0; }),
    map(function($v) { return $v * 2; };
)([1,2,3,4]);

There'd be plenty of ways to implementing something like this, but it would be an awesome addition.

nikic commented

@ragboyjr I can totally see the motivation for that, but am somewhat leery of changing the design in this direction. It looks nice with composition, but this turns a single call into map($fn)($array) -- which is possible since PHP 7, but also very un-PHPy.

Another similar feature request is in #45, which instead suggests a fluent object API on the toIter() return value.

Ha yes, it isn’t very php. How hard would it be to add a new namespace where we automatically curry the normal inter functions. Similar to the reversible functions?

nikic commented

Something like this?

use iter\{fn, curried};

$items = fn\compose(
    curried\filter(function($v) { return $v % 2 == 0; }),
    curried\map(fn\operator('*', 2))
)([1, 2, 3, 4]);

100%. Exactly.

@nikic Some proposals:

  1. I tried to refactor iter\fn::operator with evals and etc, but I didn't get anything. That $functions array contains almost the exact same code for each operator 😞

  2. May we apply PSRs in our code? Rename classes to match each file, add methods visibility and all the PSR stuff? 😄

just a random suggestion - can we use iterable namespace in 2.0 instead of iter, to be more consistent with native function naming (\iterable\map instead of \array_map, etc)

nikic commented

Version 2.0 with the rename from iter\fn to iter\func and the raise of the minimum version is now released. Otherwise only minor changes.