Hi Stas, The list has been reduced since first opening the discussion, some maintainers have come forward for some of those first mentioned.
There are still some outstanding extensions though, and I'd like it if we could move forward with this RFC: either finding maintainers or moving them out. Could you possibly find some time to push forward with this please ? Cheers Joe On Tue, Aug 23, 2016 at 4:44 PM, Johannes Schlüter <johan...@schlueters.de> wrote: > On Mon, 2016-08-15 at 10:17 +0200, Kalle Sommer Nielsen wrote: > > readline > > If removed, I guess this won't affect sapi/cli? > > It would. In 5.3 or so I moved the interactive shell to the readline > extension (php -a) in order to help distributors who like to have > extensions shared. > > I think "actual" readline functionality isn't used often in PHP, i.e. > GitHub doesn't seem to have any relevant results except phpt files, > syntax highlight descriptors etc. > https://github.com/search?l=php&p=1&q=readline&type=Code&utf8=%E2%9C%93 > > If we remove the extension and move the shell part back into sapi/cli we > have to teach distributors to link against readline or libedit and users > won't have a way to "fix" this without recompiling complete PHP. > > I'm open for a discussion (probably in a different thread) about this. > If needed I can do readline maintenance. > > > tokenizer > > Like you mentioned, I think this should be kept in the core and > > possibly maintained as a part of the parser. I do write some > > development tools every now and then and make use of this amazing > > extension and will only want it to be kept. > > The script to produce this is by me, if needed I can step in as official > maintainer. A nice thing would be if we could get rid of the script and > somehow generate this as part of the parser (which might mean making it > part of the engine) ... > > johannes > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
