Re: Pre proposal for "Class extension functions"

> On 24 Sep 2018, at 6:21 pm, Andrey O Gromov <AGromov@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