Pull Request Test Coverage Report for Build 7349487827

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.001%) to 99.012%

Totals
Change from base Build 7330553583:	0.001%
Covered Lines:	4208
Relevant Lines:	4250

💛 - Coveralls

Hello,

Thanks for the PR.

For Result, we have proceed, which acts similar to what you want to achieve here in option:

I've mentioned something similar in the original PR:

https://github.com/azjezz/psl/pull/356/files#r912345716

The conclusion in there was this one:

The same thing can be achieved by using mapOrElse() in combination with unwrap().
For your example implementation, this would mean:

$try_division = static function (int $dividend, int $divisor) use ($checked_divisor): string {
    return $checked_divisor($dividend, $divisor)->mapOrElse(
        static fn ($value) => sprintf('%s / %s = %s', $dividend, $divisor, $value),
        static fn() => sprintf('%s / %s failed!', $dividend, $divisor),
    )->unwrap();
};

From my point of view, this seems sufficient in line with your implementation as well.

If you are OK with calling mapOrElse with a final unwrap() in your codebase, I assume we don't need this and can close this?

For sure this can be done in userland! I was just imagining a way to make some operations easier after learning Rust's match syntactic sugar. For sure it can be done instead with mapOrElse() and unwrap(), it's just that it's not immediately obvious 😄

We can close it if you already concluded that you don't want a function just for this

I've given it some second thoughts and do agree that this shortcut is more than welcome. I've skimmed through some of my packages and I frequently see me using the combination of mapOrElse with unwrap. There is no alternative for this combination in rust, most likely because they have the match operator and the ? operator as shortcuts already.

But to keep things consistent throughout the codebase, I suggest to rename it to proceed. That way, it's similar to what we do in ResultInterface.

The signature should be:

    /*
     * @template Ts
     *
     * @param (Closure(T): Ts) $some
     * @param (Closure(): Ts) $none
     *
     * @return Ts
     */
    public function proceed(Closure $some, Closure $none): mixed;

That way, proceed will be used to map any possible scenario and unwind the result in one fixed type. That way, we can keep a consistent API throughout all these monad-like classes and interfaces.

The example will look like this:

$try_division = static function (int $dividend, int $divisor) use ($checked_divisor): string {
    return $checked_divisor($dividend, $divisor)->proceed(
        some: static fn ($value) => sprintf('%s / %s = %s', $dividend, $divisor, $value),
        none: static fn() => sprintf('%s / %s failed!', $dividend, $divisor),
    );
};

WDYT?

I think this one is ready too! 😄

Looks good, can you resolve conflicts so that it can be merged,

Ready to go @veewee!

Nice, thanks!