On Tue, Dec 11, 2018 at 11:33 AM Christoph M. Becker <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.
