Re: [PHP-DEV] [VOTE] PHP Technical Committee
On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka wrote: > Hi, > > The vote is now open for the RFC about introduction of the PHP Technical > Committee: > > https://wiki.php.net/rfc/php_technical_committee > > Regards > > Jakub > Hi Jakob. Sorry for not participating in the discussion phase but I would like to give my explanation on why I voted No. You made a good job in distinguishing the user-facing from the technical changes to say what can and can't be decided by the TC, but the first can't live with the second. Then, it allows the TC to have conversations and vote in private in matters that until today have always been public. Of course developers are allowed to talk to each other wherever they want, but what matters is said in public. "unless the provided implementation would result in introduction of new bugs, side effects not mentioned in the RFC, significant performance penalties not mentioned in RFC, or if there is an equivalent implementation in progress that the TC finds more appropriate." is ample enough that it can allow anything to be rejected. Overall, the idea of having a group of people that developers can ask for some guidance from is great, but that group shouldn't have any extra rights to block anything whatsoever. To demonstrate good faith and unequivocally show that this is not an attempt at a power grab, it would be a nice gesture for the authors of the RFC to include their withdrawal from ever holding a seat in the technical council in the text of the RFC itself. Best regards, Pedro
Re: [PHP-DEV] Request for RFC Karma - Enum value semantics proposal
On Fri, Apr 28, 2023, at 4:47 PM, Garet Claborn wrote: > You are correct, thank you. > > The RFC draft has been posted to > https://wiki.php.net/rfc/treat_enum_instances_as_values > > -Garet I have already explained at length on the PR thread why this is a fundamentally wrong way to approach Enums. We absolutely should work to improve the Enum collection story in PHP, but silently casting Enums to scalars is the wrong way to do it. As noted in the original Enum RFC: > As objects, Enum cases cannot be used as keys in an array. However, they can > be used as keys in a SplObjectStorage or WeakMap. Because they are singletons > they never get garbage collected, and thus will never be removed from a > WeakMap, making these two storage mechanisms effectively equivalent. WeakMap may not be not ideal, but it is more ideal and effective than introducing silent Enum->primitive casting, which we have explicitly and deliberately avoided until now. It can still be used in mostly the same way as arrays are today; the only caveat would be if you're expecting to use a mix of different types as keys, in which case the answer is to fix the code instead because that's already a broken approach. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Moving a tmpfile()?
@Robert I know windows has problems with moving files that are opened by other processes, BUT this still works fine on Windows 10 running on NTFS: rename returns true and the file really is moved (and the file is no longer automatically deleted - i suspect PHP's tmpfile() try to delete the original path on cleanup, and don't keep track of renames/movings) On Sat, 29 Apr 2023 at 14:56, Robert Landers wrote: > > On Sat, Apr 29, 2023 at 9:33 AM Dan Liebner wrote: > > > > Are there any inherent problems with moving a file created with tmpfile()? > > In practice, it seems that it can be done and the file will not be deleted > > after being moved and the file handle closed. > > > > Thanks, > > Dan > > I suspect it depends on the OS. For example, in Linux, you can delete > a file you are writing to without issues, but you cannot in Windows. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
