Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Tue, 5 Mar 2024 at 20:17, Larry Garfield wrote: > > A 3 way up-down vote doesn't make sense. What happens if none of the 3 > options reaches 66%? > > The viable options here are a single RCV vote (which we've done before), or a > single "Should we do this" vote that requires 66%, followed by a "when should > we do this" vote with 2 options, majority wins. > > --Larry Garfield Does this work for you guys? = Proposed Voting Choices = ### 1. Enhancement of Precision: Float Arguments for Sub-Second Precision **Should we extend `sleep()` to accept floats for sub-second delays?** - Yes - No **Which PHP version should implement this feature if accepted?** - 8.4 - 9.0 ### 2. Normalized Return Values on Windows **Should we modify `sleep()` on Windows for consistent return values?** - Yes - No **Which PHP version should implement this feature if accepted?** - 8.4 - 9.0 ### 3. Enhanced Return Value Precision **Should we increase `sleep()` return value precision to include fractions of a second?** - Yes - No **Which PHP version should implement this feature if accepted?** - 8.4 - 9.0 @Tim >adding a short *nix explanation of when sleep will return earlier than expected would be helpful Where should that be? in the "Introduction" section? or the "Proposal" section? (or elsewhere?)
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Hi folks. Based on earlier discussions, we've made a number of changes to the
RFC that should address some of the concerns people raised. We also had some
very fruitful discussions off-list with several developers from the Foundation,
which led to what we feel are some solid improvements.
https://wiki.php.net/rfc/property-hooks
Smaller changes:
1. We've added a PropertyHookType enum for use in reflection, which lets us get
rid of a possible exception.
2. get_mangled_object_vars()'s behavior is now defined to be the same as an
array, ie, skip hooks.
3. A final property with a final hook is no longer an error. It's just silently
redundant, like for methods.
5. Made explict what happens with recursive hook calls and method calls from a
hook. The behavior here is the same as for __get/__set.
6. Made support for #[\Override] explicit.
7. Added an FAQ regarding the property-centric approach rather than
method-centric approach.
8. Clarified that the parent::$foo::get() syntax works on a parent property
regardless of whether it has hooks.
9. Clarified that untyped properties are supported. (Though, it's 2024, please
don't use untyped properties.)
10. Clarified that interface properties cannot specify a wider write-type, for
simplicity. That could be considered as a future add-on with no BC breaks.
11. Provided an explanation of how to interpret the parent-hook access syntax.
12. Added an FAQ item explaining why a 'virtual' keyword is not feasible.
Larger changes:
0. As noted a while ago, $field has been removed.
1. I've added an FAQ question regarding the parent::$foo::get() syntax, and why
it is.
2. The $foo => expression shorthand has been removed. The legal shorthands are
now:
public string $foo {
get => evaluates to a value;
set => assigns this value;
}
3. The set shorthand (with => ) now means "write this value instead". The
non-shorthand version (set { } ) is always return void, so you have to assign
the value yourself but you get more flexibility. Having updated the examples
accordingly, I think this is actually a really nice and intuitive trade-off, as
it makes the common transformation and validation cases (eg, in constructor
promotion) even easier to follow with no redundancy.
4. On a set hook, the user may specify both a type and name, or neither. (That
is, set {} or set (Foo $newFoo). If not specified, it defaults to the type of
the property and $value, as before.
5. I restructured how the content in 2, 3, 4 is presented and moved some stuff
around so that it flows more logically (I think).
6. The restrictions around references have been softened. Specifically,
references are only disallowed if a backed property has a set hook. If it has
only a get, or if it's a virtual property, references are allowed. We also
added a future-scope section on a possible way to support assigning by
reference in the future, if there is sufficient need.
7. Interfaces may now require a hook, or just 'get'. A class may use a
hook on a 'get' interface declaration. This is the same logic as already
exists for methods; we're just copying it.
Hopefully the above changes should resolve most outstanding concerns. I do
think the updated shorthand handling is better overall, so I'm happy with it.
There also seems to be little consensus so far on naming this thing hooks vs
accessors. Absent a consensus, we'll probably stick with hooks to avoid the
effort of renaming all the things.
Thank you everyone for the feedback so far, and if you still have some, please
say so. (Even if it's just to say that you're happy with the RFC now so we
feel more comfortable bringing it to a vote.)
--Larry Garfield
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Fri, Mar 8, 2024, at 8:12 AM, Hans Henrik Bergan wrote: > On Tue, 5 Mar 2024 at 20:17, Larry Garfield wrote: >> >> A 3 way up-down vote doesn't make sense. What happens if none of the 3 >> options reaches 66%? >> >> The viable options here are a single RCV vote (which we've done before), or >> a single "Should we do this" vote that requires 66%, followed by a "when >> should we do this" vote with 2 options, majority wins. >> >> --Larry Garfield > > Does this work for you guys? > > = Proposed Voting Choices = > > ### 1. Enhancement of Precision: Float Arguments for Sub-Second Precision > > **Should we extend `sleep()` to accept floats for sub-second delays?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > ### 2. Normalized Return Values on Windows > > **Should we modify `sleep()` on Windows for consistent return values?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > ### 3. Enhanced Return Value Precision > > **Should we increase `sleep()` return value precision to include > fractions of a second?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > @Tim >>adding a short *nix explanation of when sleep will > return earlier than expected would be helpful > > Where should that be? in the "Introduction" section? or the "Proposal" > section? (or elsewhere?) That seems reasonable, yes, assuming you want the change broken up into 3 votes. I haven't actually looked at the RFC itself in detail to say if that's wise or not. Do things still work if any given subset passes but not others? Generally you would put the above into the Voting section, with a text note saying that the main votes are 2/3 and the "When" votes are 50/50. Then structure the RFC so that it breaks into 3 pieces naturally, and note in the introduction that there's 3 related changes under consideration. --Larry Garfield
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Fri, Mar 8, 2024, at 12:12 AM, Hans Henrik Bergan wrote: > On Tue, 5 Mar 2024 at 20:17, Larry Garfield wrote: >> >> A 3 way up-down vote doesn't make sense. What happens if none of the 3 >> options reaches 66%? >> >> The viable options here are a single RCV vote (which we've done before), or >> a single "Should we do this" vote that requires 66%, followed by a "when >> should we do this" vote with 2 options, majority wins. >> >> --Larry Garfield > > Does this work for you guys? This is a lot of votes for a set of pretty simple changes with minimal BC implications, and maybe there's precedent for it but I don't like voting about what version to make particular changes in. Adding a language feature like property hooks is a one-vote RFC but fixing sleep() to take/return floats and work consistently cross-platform is somehow a six-vote ballot? Is there anyone who has indicated in any way that they would vote against making all three changes because one of the three is somehow unacceptable? What if #3 fails but not #1? And I'd say leave it up to the release managers to decide what version it is appropriate for the PR implementing an approved RFC go into. Micro-managing that by voting does not sit well with me. Jim
Re: [PHP-DEV] Release Managers for PHP 8.4
On Mar 5, 2024, at 11:37 AM, Jakub Zelenka wrote: > > Please put your name forward here if you wish to be considered a candidate. > An initial TODO page has been added to the wiki and contains provisional > dates for GA and pre-releases [2]. > I'm putting my hat in to the ring again for 8.4 release manager. As for qualifications, I think I'm somewhat familiar with internals, as I maintain a PHP distribution for the IBM i platform as well as various database extensions (Db2 extensions in PECL, and now ODBC in ext/). I have done some triage of PHP changes, at least in regards to platform compatibility. The work of a release manager seems like a logical extension of that. ~cb
Re: [PHP-DEV] Re: Release Managers for PHP 8.4
> Notably, at least one of the volunteers must be a "veteran" release manager, > meaning they have participated in at least one release of PHP in the past. > The other may be an additional veteran, or more ideally, someone new to the > RM role (in order to increase our supply of veteran RMs). > > Please put your name forward here if you wish to be considered a candidate. > An initial TODO page has been added to the wiki and contains provisional > dates for GA and pre-releases [2]. Hi all, I would like to inform you all of my candidacy through this email. Regards. Saki
Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
Hi internals, Just want to resent this note about the updated RFC as there where no comments last time and I'm unsure if this was due to mailing list issues. I now have updated the RFC to allow to opt-in to new behavior on PHP 8.4 and be able to opt-out to previous behavior in PHP 9.0 via new parameter "force_float". Also the deprecation has been removed as nobody liked it. If no further comments arrive I'll like to start voting next week Friday. Best regards, Marc On 25.02.24 18:09, Marc Bennewitz wrote: Hi all, I now have updated the RFC to allow to opt-in to new behavior on PHP 8.4 and be able to opt-out to previous behavior in PHP 9.0 via new parameter "force_float". Also the deprecation has been removed as nobody liked it. Best regards, Marc On 26.09.23 12:39, Marc Bennewitz wrote: Hi internals I'd like to put a new RFC under discussion: https://wiki.php.net/rfc/integer-rounding Best, Marc
[PHP-DEV] Idea: Implicit inheriting function argument & return type-hint
Hi internals,
Based on the discussion of "Property accessor hooks, take 2" and the
set-hook argument type - I got to wonder why we still define "no type"
as `mixed`.
As the pseudo type `mixed` exists since PHP 8.0, which is already
out-of-date, I have the feeling it would be better to force people to
explicitly write `mixed` to widen the type of an overwritten function
and let "no type" inherit the argument and return type of the parent.
Example:
class A {
public function typed(int $var): int { return $var; }
public function untyped($var) { return $var; } // implicit mixed as
no overwrite
}
class B extends A {
public function typed($var) { return $var; } // implicit int as
inherited from overwritten function
}
class C extends A {
public function typed(mixed $var):mixed { return $var; } //
explicit mixed to widen the type
}
That do you think?
This is just something that come to mind without having the knowledge
nor time for this kind of RFC or implementation.
Greetings,
Marc
[PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
Hello, Internals I created an wiki for `grapheme_str_split` function. Please see: https://wiki.php.net/rfc/grapheme_str_split I would like to "Under Discussion" section. Best Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
