On 24.12.2018 at 08:38, Dmitry Stogov wrote: > On 12/22/18 1:32 PM, Nikita Popov wrote: > >> My main concern here is that this is a very new extension and I think >> that apart from you barely anyone had a chance to actually implement >> something based on it and gain experience using the proposed API. >> Bundling an extension with PHP means that the API becomes frozen in time >> and it becomes very hard to change anything. >> I think that having FFI support is important, but I'm afraid that once >> we bundle this extension and it will see more usage, it will quickly >> turn out that the API needs to change to make it easier to use or >> accommodate more use-cases. > > The API almost completely repeats LuaJIT and Python CFFI (that are > stable). Something might need to be improved, of course, but only in > case the extension is going to be widely used.
If we are concerned about the API stability, we could mark the extension as experimental and exempt it from our usual BC guarantee, as suggested by Niklas[1]. On the other hand, if PHP 8 will be next after PHP 7.4, this may not even be necessary. > The main reason, I like to have this in core - future integration with JIT. It seems to me that JIT integration of FFI isn't the whole story, but rather an intermediate step to be able to offer built-in functionality written in PHP in the long run, which could be a huge enhancement. Am I correct? Anyhow, my main concerns regarding the proposal are that people could easily be led into thinking that FFI is *the* new way to interface with external code, rendering classic extensions obsolete, and that interfacing on the ABI level is even more error-prone than interfacing on the C API level. Both concerns could be alleviated by good documentation, though. [1] <https://externals.io/message/103613#103623> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
