> On 24 Sep 2018, at 6:21 pm, Andrey O Gromov <agro...@alfabank.ru> wrote:
>
> Hello.
>
> I want to do RFS proposal for new language concept - Class extension
> functions.
>
> Syntax will looks like:
>
> function DateTime->localTime() {
> return $this->format('H:i');
> }
>
> $date = new DateTime();
>
> echo $date->localTime();
>
>
> Realisation draft already written (
> https://github.com/rjhdby/php-src/commit/a54d7d3f8504d2e15908bb0e44de0b2f87683872
> )
>
> It is interesting or not?
From a user land perspective, I think this is a proverbial truck of boxes of
cans of worms.
For reference: monkey patching methods onto built-in classes is what gives you
shenanigans like the discussion about `[].smoosh` in Javascript.
This just opens up a ridiculously wide scope for “we can’t add method X because
of a BC break in userland code”.
The *only* way I could get behind this, is if it’s made clear in the
docs/RFC/wiki/written in the sky/etched on the moon via laser, that literally
no future RFC will ever consider “a user land BC break because of ‘class
extension functions’ in the wild" a valid reason to reject the RFC. The only
officially supported use of this, should be for the one good use of monkey
patching in JS: polyfills for missing functionality in older runtimes. For
example, SplFileObject was added in PHP 5.1.0, but didn’t have an fread()
method until 5.5.11.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
