On 12/24/18 4:50 PM, Christoph M. Becker wrote: > 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.
Right. > >> 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? In current state FFI is more like a great toy. It allows to quickly prototype on top of binary interfaces, but the resulting performance is going to be poor, because of interpretation overhead. However, LuaJIT proved that it's possible to integrate JIT and FFI and achieve almost C performance. This could open a real door for writing PHP extensions in PHP itslef. > 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. Agree. FFI is dangerous, especially for programmers without C background. Without FFI they just can't make a lot of harm. However, the proposal offers to enable FFI only for preloaded files (and CLI), by default. Thanks. Dmitry. > > [1] <https://externals.io/message/103613#103623> >
