On 12/11/18 11:21 PM, Levi Morrison wrote:
On Tue, Dec 11, 2018 at 11:33 AM Christoph M. Becker <cmbecke...@gmx.de<mailto:cmbecke...@gmx.de>> wrote: On 06.12.2018 at 17:26, Marco Pivetta wrote: > Looks very interesting, especially for simplifying the landscape of > extensions. > > Still, the amount of abbreviations and naming issues is quite huge: needs a > lot of care on that end, IMO. Even just the name of the type (`FFI`) can > simply be expanded to `ForeignFunctionInterface`. By the same reasoning, http_response_code() is a bad name, and should be changed to hyper_text_transfer_protocol_response_code(). Same for parse_url(), which should better be named parse_uniform_resource_locator(). ;) Don't get me wrong, I'm all for having self-explaining identifiers, but if within a given domain an abbreviation is *very* common, it makes not much sense to spell it out. And FFI is very common when interfacing to C from a scripting language. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php My only nit on naming is that "FFI" needs to specify in some way *which* FFI. Although an FFI with C is very common it is not the only one that exists. Naming this "CFFI" or such would solve this. Personally, I think FFI is more common and better. Just ask google... I think, Python uses CFFI, because they have an older FFI implementation (based on ctypes). Thanks. Dmitry.
