Re: [PHP-DEV] ext-random: add random_float() ?
2022年12月29日(木) 22:25 Tim Düsterhus : > Hi > > On 12/20/22 07:27, Go Kudo wrote: > > Now that my work is done, I was thinking about a proposal for a > sunsetting > > of existing functions for PHP 8.3 based on the features introduced in > > ext-random, and I realized that there is no alternative to `lcg_value()`. > > > > Essentially, this could be completely replaced by > > Random\Randomizer::getFloat(), but there are easier `random_int()` and > > `random_bytes()` functions for ints and strings. > > > > The Randomizer may be overkill and complicated for PHP use cases where > > random number reproducibility is not required in many cases. > > > > So, why not add a `random_float(): float` function? This function, like > the > > others, uses CSPRNG and returns a value between 0.0 and 1.0. This > behavior > > is `Closed` `Closed`. > > > > Opinions are welcome. > > I'm not convinced that a random_float() function is a good addition. > Especially not with the proposed behavior: > > 1. Using the (0, 1, ClosedClosed) behavior does neither match > Randomizer::nextFloat(), nor Randomizer::getFloat(). > > 2. I consider the ClosedOpen behavior to be the "correct" default, > because the interval can then be cleanly split into equally sized > subintervals. > > > > But even when random_float() would work like Randomizer::nextFloat() > (i.e. (0, 1, ClosedOpen)), I would not consider this a good addition: > > Users would likely attempt to scale the returned value to arbitrary > ranges using the `($min + random_float() * ($max - $min))` construction, > instead of using Randomizer::getFloat(). > > As per Drawing Random Floating-Point Numbers from an Interval. Frédéric > Goualard, ACM Trans. Model. Comput. Simul., 32:3, 2022 this construction > is unsafe, because is is both biased and also may return values outside > the expected interval. > > > > So random_float() would rather need to behave like > Randomizer::getFloat() instead of Randomizer::nextFloat() and then it > would not be much simpler than using the Randomizer class directly. I > further expect that needing to generate random floats is much rarer than > needing to generate random integers or random bytes (for tokens), thus > having convenience functions for those two, but not floats is acceptable > and keeps the API surface simple, making it easier to document all the > gotchas. Users can add convenience wrappers themselves. > > Best regards > Tim Düsterhus > Hi Tim Thank you for the clear explanation. I generally understood the intent. And once again I recognized that floating point random numbers are difficult to handle. I agree that the addition of the random_float() function is inappropriate. However, with the goal of deprecating it in PHP 8.3 and deprecating RNGs with virtual machine dependent state in PHP 9.x, I think we need to provide a useful replacement for the lcg_value() function. Do you have any good ideas on this? Most likely, since the random numbers generated by lcg_value() are of low quality and do not appear to be used very often, one idea would be to simply remove it. However, I believe that the absence of an alternative function is likely to generate negative opinions about its elimination. Regards, Go Kudo
Re: [PHP-DEV] [RFC][Vote] Asymmetric Visibility
Hi, I was looking at the current vote of this RFC and I stumbled upon Theodore's remark that the RFC feels unfinished as it can't be used in conjunction with readonly properties/classes. The RFC disallows (for the time being) the mixing of readonly with explicit asymmetric visibility. And I was happy about it. Thus I didn't feel the need to comment about it so far. The main motivation given in the readonly RFC was value objects. And as far as I understand, one of the main reasons was to reduce boilerplate code (esp. public getters). readonly works fine for value objects. But looking at entities, there is no solution so far. Thus I still (might) need to provide public getters. And because of the limitations of readonly, there was/is a need for asymmetric visibility. I doubt, there would be any need for readonly if we would have had asymmetric visibility first. And (using asymmetric visibility) I assume, developers should be able to ensure that a property is 1. only initialized once, 2. inside the limited scope of a class, and 3. not overwritten during the lifetime of the object. I'd be interested in a use case where you would really like to ensure this on the engine level. To go one step further, I would even ask the heretical question if we should discourage/deprecate readonly once we have asymmetric visibility. ;-) Regards Thomas Am 07.01.23 um 00:37 schrieb Larry Garfield: I am hereby opening the vote on the Asymmetric Visibility RFC: https://wiki.php.net/rfc/asymmetric-visibility Voting will be open for 2 weeks. While we would certainly prefer if everyone voted in favor, for those who vote against the authors kindly request that you indicate why, using the second poll question or comment section afterward. Thank you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] base64url format
On Mon, Jan 9, 2023, at 12:49 PM, Sara Golemon wrote:
> I've been working with JWTs lately and that means working with Base64URL
> format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
> This is essentially the same thing as normal Base64, but instead of '+' and
> '/', it uses '-' and '_', respectively. It also allows leaving off the
> training '=' padding characters.
>
> So far, I've just been including polyfills like this:
>
> function base64url_decode(string $str): string {
> return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
> (strlen($str) % 4)) % 4, '='));
> }
>
> function base64_encode(string $str): string {
> return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
> }
>
> These work fine, but they create a LOT of string copies along the way which
> shouldn't be necessary.
> Would anyone mind if skipped RFC and just added `base64url_encode()` and
> `base64url_decode()` to PHP 8.3?
>
> Can hold a vote if anyone objects, but this seems fairly non-controversial.
>
> -Sara
It sounds to me like there's enough discussion to be had on the How to warrant
a formal RFC. I get the sense once the bikeshedding is done it will pass, but
it's going to need the discussion/review.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] base64url format
how about base64_encode(string $string, int $flags = 0): string
with $flags accepting BASE64_RFC4648 and BASE64_NO_PADDING
or something to that effect?
On Mon, 9 Jan 2023 at 22:56, David Gebler wrote:
>
> On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans
> wrote:
>
> > On 9 January 2023 18:49:28 GMT, Sara Golemon wrote:
> > >I've been working with JWTs lately and that means working with Base64URL
> > >format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
> > >This is essentially the same thing as normal Base64, but instead of '+'
> > and
> > >'/', it uses '-' and '_', respectively. It also allows leaving off the
> > >training '=' padding characters.
> > >
> > >So far, I've just been including polyfills like this:
> > >
> > >function base64url_decode(string $str): string {
> > >return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
> > >(strlen($str) % 4)) % 4, '='));
> > >}
> > >
> > >function base64_encode(string $str): string {
> > >return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
> > >}
> > >
> > >These work fine, but they create a LOT of string copies along the way
> > which
> > >shouldn't be necessary.
> > >Would anyone mind if skipped RFC and just added `base64url_encode()` and
> > >`base64url_decode()` to PHP 8.3?
> >
> > Should these be new functions, or options to base64_encode instead? I'd
> > guess base64_decode could just accept both?
>
>
> I think from a UX/DX perspective, separate functions would be my
> preference, base64_url_encode and base64_url_decode (extra underscore which
> I feel is more consistent with PHP stock library). One consideration though
> is that base64_urlencode or base64_url_encode are function names which are
> likely already defined by a number of userland projects or libraries, since
> it's a very common thing to do with the prevalence of JWTs, so if the RFC
> process is being bypassed in this case, a new optional parameter to
> base64_encode might be better. But I think it would be weird to have
> base64_encode(bool $urlEncode = false) or something, which is presumably
> what it would look like.
>
> Dare I float the suggestion of a Base64 class, making base64_encode and
> base64_decode functions aliases for Base64::encode() and Base64::decode()
> respectively, then new Base64::urlEncode() and urlDecode() methods?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
