Harry Lewis

This looks like a problem that would be better-solved with a first-party object-oriented API for primitive types (a bit like JavaScript). Honestly the syntax looks a bit odd and as per the example, referencing global functions as strings is an anti-pattern IMO (not friendly for IDEs / refactoring!).

For example:

$result = ("Hello World") // string
    ->htmlentities(...)
    ->split(...) // array
    ->map(fn ($x) => strtoupper($x))
    ->filter(fn($v) => $v != 'O');

Still hard to read. No extra benefits.

The only clean solution is to use scalar types (string, int, float, boolean) and arrays like objects:

$result = "Hello World"->htmlentities()->split()->map(strtoupper(...))->filter(fn($v) => $v != 'O');

Chain, clean oop, readable, IDE hint, no value parameter, no prefixes and an opportunity to correct the functions inconsistency. It could works beside functions: strtoupper($name) and $name->toUpper().

• Interface shall stay light, pure contracts defining expectations, else they are just abstract classes with multi-inheritance.
• If multi-inheritance is the subject, a specific RFC shall be done on this.
• An other away might be to dig back this RFC to add interface to traits: https://wiki.php.net/rfc/traits-with-interfaces