feat(option): add Option::proceed() method

[devnix]

This is another idea of implementing a match method that I had after learning more bits of Rust: https://doc.rust-lang.org/rust-by-example/std/option.html

WDYT?

[coveralls]

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

[veewee]

Hello,

Thanks for the PR.

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

psl/src/Psl/Result/ResultInterface.php

Lines 132 to 145 in 0aa7117

	/**
	* Unwrapping and transforming a result can be done by using the proceed method.
	* The implementation will either run the `$on_success` or `$on_failure` callback.
	* The callback will receive the result or Throwable as an argument,
	* so that you can transform it to anything you want.
	*
	* @template Ts
	*
	* @param (Closure(T): Ts) $success
	* @param (Closure(Throwable): Ts) $failure
	*
	* @return Ts
	*/
	public function proceed(Closure $success, Closure $failure): mixed;

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?

[devnix]

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

[veewee]

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?

[devnix]

I think this one is ready too! 😄

[veewee]

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

[devnix]

Ready to go @veewee!

[veewee]

Nice, thanks!