[PHP-DEV] Re: [RFC][Discuss] Covariant return- and contravariant parameter- types
On Mon, Nov 26, 2018 at 2:25 PM Levi Morrison wrote:
>
> I am happy to announce my latest RFC, [Covariant Returns and
> Contravariant Parameters][1], is open for discussion. If you do not
> recognize those terms then hopefully the introduction coupled with the
> [examples][2] will help. Here is one snippet that demonstrates
> covariant return types:
>
> interface Repository {
> function fetch(int $id): ?Entity;
> }
>
> class UserFactory implements Repository {
> function fetch(int $id): ?UserEntity {
> /* Since UserEntity is an Entity, this is now allowed */
> /* ... implementation ... */
> }
> }
> ?>
>
> Covariant return types and contravariant parameter types are highly
> requested features; here are a few of the bug reports:
>
> * https://bugs.php.net/bug.php?id=71825
> * https://bugs.php.net/bug.php?id=72442
> * https://bugs.php.net/bug.php?id=75385
> * https://bugs.php.net/bug.php?id=75823
>
> There is a [preliminary implementation][3] that is available. It will
> not be rebased during discussion to allow people to check out the code
> and get updates without worrying about it breaking. The code quality
> can definitely be improved, and there are still a few todo comments in
> the code.
>
> Please do not discuss the items found in [Future Scope][4] as part of
> this thread, which includes discussing types such as `mixed`,
> `scalar`, `numeric`, etc.
>
> I look forward to your feedback, and especially with your
> experimentation with the implementation.
>
> Levi Morrison
>
> [1]: https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
> [2]:
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#examples
> [3]: https://github.com/php/php-src/compare/master...morrisonlevi:variance2
> [4]:
> https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#future_scope
It has been two weeks now. If you want to provide any feedback, or
follow-up on anything from the discussion, please do so soon. I hope
to put this to vote before the end of the year.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface
On Tue, Dec 11, 2018 at 11:33 AM Christoph M. Becker 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.
Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface
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
Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface
On Thu, Dec 6, 2018 at 9:54 AM Dmitry Stogov wrote: > I would like to start discussion of FFI RFC https://wiki.php.net/rfc/ffi > > I said this already privately, but I just want to repeat here in the open. This thing is DANGEROUS. I know you know that. I'm not telling you, I'm stating it for every casual reader of this list. So while discussing details of naming and calling conventions is important, my #1 concern is how we avoid creating a potentially fatal situation for users. I like the "ffi.enable=preload" idea you came up with. I think that addresses the actual needs that FFI is trying to solve without completely opening the fire hose. Big +2 to that idea. (Although it's not expressed, I'm assuming this is PHP_INI_SYSTEM as anything else would be silly) I'm not super enthused by having "ffi.enable=true" even be an option, to be quite honest. For CLI, sure but the damage that can be wrought from a web server exposed to the internet is non-trivial. And I'm also going to let my prejudice show: I don't trust someone who doesn't know how to write an extension in C to use FFI. Heck, I've seen some extensions that make me wince pretty hard, but at least there I feel like they've had to do something more thoughtful than copy-paste an example from stack overflow and change a name or two without any concern for how an unmanaged language works. And for the record, since some of my tweetings have been misconstrued, I am currently +1 on the idea as a whole. I just want flashing neon signage a mile high and a heavy, even frustrating barrier to access. The consequences of being too lax are too high. -Sara
Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface
On 11.12.18 16:42, Marco Pivetta wrote: > People who don't know what FFI is, don't need it. I think this is a very dangerous way of designing, writing and documenting software. I appreciate your efforts in pushing this forward, but please reconsider when approaching the naming problematic, because this point of view is extremely flawed. I'm fine with FFI and it matches other scripting languages (python, ruby, lua). Not saying that's the reason to not change it but seems to me the name is most appropriate in its field; I see no harm. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface
> People who don't know what FFI is, don't need it. I think this is a very dangerous way of designing, writing and documenting software. I appreciate your efforts in pushing this forward, but please reconsider when approaching the naming problematic, because this point of view is extremely flawed. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Tue, Dec 11, 2018 at 4:37 PM Dmitry Stogov wrote: > Hi Marco, > > > Some API and naming issues may be changed, e.g. FFI::array_type() was > renamed to FFI::arrayType(). > > Changing FFI into ForeignFunctionInterface looks, like an overhead. > People who don't know what FFI is, don't need it. > > > I surprised, there are no any problem reports... > > It seems, like few people on @internals tried it. > > > Thanks. Dmitry. > > > > > -- > *From:* Marco Pivetta > *Sent:* Thursday, December 6, 2018 7:26:57 PM > *To:* Dmitry Stogov > *Cc:* PHP Internals List > *Subject:* Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface > > 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`. > > Just my 2 cents. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > On Thu, Dec 6, 2018 at 4:54 PM Dmitry Stogov wrote: > > Hi Internals, > > > I would like to start discussion of FFI RFC https://wiki.php.net/rfc/ffi > > > This extension allows calling C function and accessing C data structures > in pure PHP. > > In conjunction with preloading it gives a possibility to write PHP > extension in PHP itself. > > The extension was tested on attempt to build TensorFlow PHP binding. > > > Thanks. Dmitry. > >
Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface
Hi Marco, Some API and naming issues may be changed, e.g. FFI::array_type() was renamed to FFI::arrayType(). Changing FFI into ForeignFunctionInterface looks, like an overhead. People who don't know what FFI is, don't need it. I surprised, there are no any problem reports... It seems, like few people on @internals tried it. Thanks. Dmitry. From: Marco Pivetta Sent: Thursday, December 6, 2018 7:26:57 PM To: Dmitry Stogov Cc: PHP Internals List Subject: Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface 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`. Just my 2 cents. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Thu, Dec 6, 2018 at 4:54 PM Dmitry Stogov mailto:dmi...@zend.com>> wrote: Hi Internals, I would like to start discussion of FFI RFC https://wiki.php.net/rfc/ffi This extension allows calling C function and accessing C data structures in pure PHP. In conjunction with preloading it gives a possibility to write PHP extension in PHP itself. The extension was tested on attempt to build TensorFlow PHP binding. Thanks. Dmitry.
