Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/24/2017 5:42 PM, Fleshgrinder wrote: > I will extend it with some examples. > > I guess that that would be useful in weak mode. Will try to hack it in. > > I am currently also working on another RFC that adds a `Convertible` > interface with a single `into` method that has its return type set to > `scalar` where objects can opt-in to become `scalar` compatible. Even in > strict mode. The idea is that the object's `into` method is > automatically called by the engine and the receiver gets the canonical > `scalar` value that represents the object. This is specifically useful > for value objects that often represent single `scalar` values in a type > safe manner. > Added some examples but I will stop now working on anything because people already start complaining again. Contributing to PHP is like kicking a combat dog ... let's wait for some support for this feature in general first. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
Hi Levi,
Levi Morrison wrote:
On Wed, Dec 6, 2017 at 12:49 PM, Nikita Popov wrote:
Hi internals,
I'd like propose optional support for explicitly marking by-reference
argument passing at the call-site, in addition to the declaration-site:
https://wiki.php.net/rfc/explicit_send_by_ref
In short, while currently we have
function byRef(&$ref) {...}
byRef($var);
this proposal would also allow
function byRef(&$ref) {...}
byRef(&$var);
so that the use of by-reference passing is obvious without having to
consult the function declaration.
I think we ought to commit to requiring the ampersand at the call site
some point in the future. As others have noted it provides little
benefit at the call site if it is not required.
However, there is an area where this does provide value that others
have not yet mentioned or thought of: `callable` parameters.
public function apply(callable $f) {
return $f(&$this->data);
}
This requires the callable to accept the argument by reference,
something we cannot currently require. Of course this is rarely
needed; I am merely pointing out this feature is more than a syntactic
hint to humans.
Based on the current discussion I would vote yes on this RFC, despite
the concerns raised by others.
Perhaps more useful is the inverse: in future, we could require that a
callable *not* take a value by-reference unless the caller asks for it.
That would prevent potential monkeying with the scope of the caller by
the callee — if right now you do $f($this->data), you might forget that
$f could take that parameter by reference and gain the ability to modify
that variable indefinitely…
Thanks
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/24/2017 5:30 PM, Nikita Popov wrote: > I think this RFC could benefit from displaying some use-cases for this type > annotation. I can't recall any recent instance where I would have found > this specific type combination useful, though I'm sure there are good > examples. > > I also wonder whether in weak typing mode, scalar should also accept > __toString objects (and cast them to string), similarly to how a > bool|int|float|string union would behave. > > Nikita > I will extend it with some examples. I guess that that would be useful in weak mode. Will try to hack it in. I am currently also working on another RFC that adds a `Convertible` interface with a single `into` method that has its return type set to `scalar` where objects can opt-in to become `scalar` compatible. Even in strict mode. The idea is that the object's `into` method is automatically called by the engine and the receiver gets the canonical `scalar` value that represents the object. This is specifically useful for value objects that often represent single `scalar` values in a type safe manner. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On Sun, Dec 24, 2017 at 3:34 PM, Fleshgrinder wrote: > Hi Internals! > > I prepared a PR to add the `scalar` pseudo-type to PHP after the > discussions around adding a `mixed` pseudo-type. I strongly believe that > it makes sense to provide the most common primitive union types with > handy aliases even if we are going to add union types in the future to PHP. > > https://github.com/php/php-src/pull/2987 > > I added support for parameter type covariance and return type > contravariance to make it as useful in daily development as possible. > > I will provide the RFC write-up asap at: > > https://wiki.php.net/rfc/scalar-pseudo-type > I think this RFC could benefit from displaying some use-cases for this type annotation. I can't recall any recent instance where I would have found this specific type combination useful, though I'm sure there are good examples. I also wonder whether in weak typing mode, scalar should also accept __toString objects (and cast them to string), similarly to how a bool|int|float|string union would behave. Nikita
[PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
Hi Internals! I prepared a PR to add the `scalar` pseudo-type to PHP after the discussions around adding a `mixed` pseudo-type. I strongly believe that it makes sense to provide the most common primitive union types with handy aliases even if we are going to add union types in the future to PHP. https://github.com/php/php-src/pull/2987 I added support for parameter type covariance and return type contravariance to make it as useful in daily development as possible. I will provide the RFC write-up asap at: https://wiki.php.net/rfc/scalar-pseudo-type -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reproducible Builds Support
On 12/15/17 at 11:54am, Sebastian Bergmann wrote: > Am 15.12.2017 um 11:13 schrieb Jordi Boggiano: > > I guess an alternative fix would be for someone to actually fix the Phar > > extension so addFromString has a filemtime parameter you can pass the > > desired mtime to. I have not checked whether addFile suffers from the same > > issue or not, but possibly it needs to be fixed to read the mtime from the > > file you add. > > +1 I'm not sure if timestamps are the issue, the created phar.phar binary is non-reproducible as can be seen in this diff. I'll do some more digging :) https://tests.reproducible-builds.org/archlinux/extra/php/php-7.2.0-2-x86_64.pkg.tar.xz.html -- Jelle van der Waa -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
