pawaclawczyk / scalp Goto Github PK

See line 40. Iterator should be advanced only when placeholder is replaced with value.

Type partial function represents a function which is undefined for some elements of the domain.

Example

f(x) = 42 / x is not defined at x equal 0

Minimal interface

interface PartialFunction
{
    public function isDefinedAt($x): bool;
    public function __invoke($x);
}

Maybe some additional logic and encapsulation in trait could be a good idea.
TDB

Example of current usage of regular expression.

private function elementId(string $propertyName): Option
{
    preg_match('/^_(\d+)$/', $propertyName, $matches);

    return isset($matches[1]) ? Some((int) $matches[1]) : None();
}

Scalp\PatternMatching\Deconstruction trait provides construct and deconstruct methods, holds internally data that represents construction arguments.

Problem related with current implementation:

1. Destruction::construct must be called manually with right arguments. It's easy to forget or passed wrong arguments.
2. Constructor arguments are duplicated, one copy is managed by object and second is hold inside trait.

Improvement proposals:

1. Destruction::deconstruct could throw exception when trying to deconstruct object that was never constructed.
2. Trait should be replaced with abstract class, __construct should be used to bind type construction arguments. In this case __construct should be protected agains extension in subclasses. Abstract method should be provided to let subclasses do finish object construction.

I see that scalp has a partial function, but it looks like said function expects that all arguments will be passed during invocation. What would it take to add a currying?

Example of usage with map method.

class Counter
{
    public static function zero(): Counter
    {
        ...
    }

    public function increment(int $step = 1): Counter
    {
        ...
    }
}

$res0 = Some(Counter::zero())
    ->map(__::increment())
    ->map(__::increment())
;

println($res0);

$res1 = $res0
    ->map(__::increment(3))
;

println($res1);

Some[Counter](Counter(2))
Some[Counter](Counter(5))

https://github.com/scala/scala/blob/2.12.x/src/library/scala/Option.scala

In some of methods in Scala's implementation of Option and Try parameters are passed by name. In PHP we do not have such possibility and we have to pass evaluated instances of expected type. As an extension we could allow to pass zero parameter functions that returns expected type.

Examples of partially applied

• functions
• anonymous functions (closures)
• class static methods
• object methods
• callable objects

function f($x, $y) { return ... }

$g = function ($x, $y) { return ... }

class F
{
    public static function sf($x, $y)
    {
        return ...
    }

    public function m($x, $y)
    {
        return ...
    }

    public function __invoke($x, $y)
    {
        return ...
    }
}

$fc = new F();

papply(f, __, 2);              // => f(__, 2)
papply($g, __, 2);             // => $g(__, 2)
papply(F::class, 'sf', __, 2); // => F::sf(__, 2)
papply($fc, 'm', __, 2);       // => $fc->m(__, 2)
papply($fc, __, 2);            // => $fc(__, 2)

flatMaps and recoverWith are protected with check that ensures the passed callable will return an expected type ie. Option or TryCatch.

In case of passing partially applied function the real function is wrapped in callable that does not have return type hinting.

At this moment Success::flatMap and Failure::recoverWith functions use function restrictCallableReturnType to check whether callable passed as argument has defined return type to TryCatch. It rises TypeError in case when return type is not defined or it is different than expected.

The proposal is to add checks enforcing also callable arguments types, ie example check input argument of callable passed to TryCatch::map or TryCatch::filter or similar functions. Type checks could be also used for checking consistency of functions passed to methods like TryCatch::transform.

Instead of using functions that throws TypeError directly we can introduce checkers returning boolean type and use them in combination with assert.

Right now when type is matched it is expected that number of provided patterns must be the same as number of arguments used for construction. This behavior is unexpected when discussing types constructed with variadic number of arguments. It could be possible to provide different case pattern for different number of arguments in constructor.

In example below three commented statements will be break by InvalidPatternsNumber exception.

<?php

declare(strict_types=1);

require_once __DIR__.'/../vendor/autoload.php';

use Scalp\Collection\Tuple;
use function Scalp\PatternMatching\match;
use function Scalp\PatternMatching\Type;
use function Scalp\PatternMatching\Any;
use function Scalp\println;

function tupleName(Tuple $tuple): string
{
    return match($tuple)
        ->case(Type(Tuple::class, Any()), function () { return 'Singleton'; })
        ->case(Type(Tuple::class, Any(), Any()), function () { return 'Pair'; })
        ->case(Type(Tuple::class, Any(), Any(), Any()), function () { return 'Triple'; })
        ->case(Type(Tuple::class), function () { return 'Other tuple'; })
        ->done();
}

//println(tupleName(new Tuple(1, 2)));
println(tupleName(new Tuple(1)));
//println(tupleName(new Tuple(1, 2, 3, 4)));
//println(tupleName(new Tuple(1, 2, 3)));

Catchable fatal error: Object of class [SomeClass] could not be converted to string in /app/vendor/scalp/scalp/src/Scalp/Utils/Success.php on line 115