[PHP-DEV] Re: [RFC][Vote] New Curl URL API
On 05/07/2022 00:34, Pierrick Charron wrote: All recent discussions show that we are not even close to getting a consensus on how the new CurlUrl OO API should be done. After changing my mind 300 times in the last day, I decided to only propose the procedural implementation that stays consistent with other functions of the ext/curl to target 8.2. I know this is not the ideal scenario, but with 8.2 feature freeze in two weeks, this is I think the only approach that will not put us in a potentially bad/harmful situation for a better future with ext/curl. I'm voting no on this one based on the discussions from R11. The deadline being close is not a good enough reason to rush a change like this that will be difficult to unwind later. I agree with some of the other comments made that it would be preferable to come up with a more generic solution that can be used by multiple components rather than something specific to Curl. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [Under Discussion] New Curl URL API
On 22/06/2022 05:38, Pierrick Charron wrote: Feel free to give any feedback, concern or support :-) This should preferably be namespaced. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: NULL Coercion Consistency
On 28/05/2022 03:36, Craig Francis wrote: In this case, two of my clients are considering the cost of modifying their code (by adding a load of `?? ''` everywhere), and they would rather avoid that (time consuming, and makes their code more complicated). Alternatively, they may wish to define their own functions that do take null and then run a find / replace or rector rule to convert them over. I would still recommend ?? because it's the most future proof. We have passed two RFCs in recent months which will eliminate default-nulls in 2 of the 3 major variable sources in the engine (the remaining one being arrays), and that too may eventually find itself promoted. If it's a framework, I would suggest adding methods for explicitly getting a string that defaults to '' instead of null. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][Under discussion] Create a global login system for php.net
On 28/05/2022 10:53, Aaron Junker wrote: When you have feedback to a specific point of the RFC, please use the corresponding number used in the RFC. To point 1, there was a time I was thinking about implementing a system ourselves (I was working on website prototypes at the time). That being said, as you identified creating our own system requires resources we don't have, and PHP is bad at infrastructure (lack of resources / specialists). For that reason I think the sensible thing to do would be to use Github. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Removal of ${} string interpolation in PHP 9
On 20/05/2022 10:05, Ilija Tovilo wrote: So unless there are concerns I will amend that in the RFC. Erroring it out makes sense to me. As we don't include any target version specification in PHP files, the safest bet it so prevent the silent change from potentially leaking through the introduction of a parser error. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Early feedback on encrypted session PR
On 18/05/2022 16:23, Craig Francis wrote: If the Session ID continued to work as the Identifier, but the client was given the Session ID and a Random Key (could be concatenated together for the cookie)... that means the Random Key would not be stored on the server, and could protect the session if there was a vulnerability on the server/website (e.g. attacker being able to see the directory listing of session files)... I'm not sure how much of a benefit that will actually provide, vs the risk of it going wrong (e.g. future PHP changing encryption algorithm). Personally I usually just throw the session key through a one-way hash so the original session ID never gets written to a backing store. I'm not sure why reversible encryption needs to take place? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Early feedback on encrypted session PR
On 17/05/2022 21:36, David CARLIER wrote: I wanted a more general but early feedback on the idea itself https://github.com/php/php-src/pull/3759 The same question that has already been asked on github: What is the motivation? What is it meant to achieve? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] NULL Coercion Consistency
On 08/05/2022 11:48, Jordan LeDoux wrote: This is not the case with null. If you use the unset() function on a variable for example, it will var_dump as null *and* it will pass an is_null() check *and* it will pass a $var === null *and* it will return false for an isset() check. Null loses these qualities if it is cast to *any* scalar. Fortunately the writing is on the wall for the undefined cases, but that doesn't take away from your argument. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Undefined Property Error Promotion
On 21/04/2022 22:45, Mark Randall wrote: I have now opened voting on Undefined Property Error Promotion. https://wiki.php.net/rfc/undefined_property_error_promotion The vote has concluded. The RFC has been passed with 31 votes (86%) in favour, 5 against. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: PHP 8.2 Release Manager Selection
On 25/04/2022 12:51, Christoph M. Becker 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 could potentially be interested in helping out with this, but I do have a question about it, mainly, why hasn't most of this been automated at this point? I was reading through the release process notes and am not seeing any obvious blocks on most of it that could not be accomplished via a suitable CI/CD pipeline. Is it just a matter of someone having time available to do it? The one thing which does make me ponder is would we need to assign a GPG key to the build process? I'd be happy to give some of my time later this year to further investigate this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Stricter implicit boolean coercions
On 26/04/2022 10:54, Andreas Leathley wrote: Any non-empty string (except "0") is converted to true and any non-zero integer or float is converted to true. If we could get rid of "0" being false, that alone would be a huge benefit for the language in the long run. I know why it exists, but I don't think it should. In fact it never should have existed in the first place. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 22/04/2022 21:30, Rowan Tommins wrote: Do you not have even a little bit of hope that we could make that less confusing, since we're breaking everyone's old code anyway? I seem to remember we had a discussion years ago about deleting unset on properties, but it was being used for a very popular proxy manager to force them to be routed to __get. The rule that anything typed must be initialized, nullable or not, is clearish enough. You could special case nullable, but then it's an extra rule to learn beyond "typed = needs to be initialized". -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 22/04/2022 14:42, Rowan Tommins wrote: As with your previous RFC, I approve of this in principle, but am frustrated how little time has been spent considering the edge cases, such as the ones I mentioned here: https://externals.io/message/117487#117487 Accessing an unset property, which currently emits a warning, will instead throw an Error. If a property has already been written to via some mechanism, then the property exists and this RFC does not apply, no warning or error should be expected. It's a different responsibility to handle the guards against writing to one which has not been defined (AllowDynamicProperties RFC). Re: Case 4, an untyped property without its own initializer is effectively defaulted to null. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] Undefined Property Error Promotion
Internals, I have now opened voting on Undefined Property Error Promotion. https://wiki.php.net/rfc/undefined_property_error_promotion Voting ends 2022-05-05 Summary: This RFC seeks to prevent execution continuing if the user has accessed an undefined property without specifying that it was their intent to potentially do so. This RFC is designed to compliment the Undefined Variable Error Promotion, and Deprecate Dynamic Properties RFCs that have already passed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Property Error Promotion
On 06/04/2022 19:38, Larry Garfield wrote: On the last point, regarding stdClass, I think the question is whether we want it to be consistent with classed object properties (throw) or with associative arrays (warnings). stdClass is kind of an uncomfortable middle between those two. I'm not sure which is better to align with, although I almost never use stdClass and tell others to avoid it as well so it doesn't really matter to me. :-) My preference is to treat it like any other property, but I am open to hearing additional comments on this. I'm not sure how much conversation we can expect on this one, if it remains quiet I intend to open the vote in a week or so. As a tangent, R11 has had some comments made about a better method for indicating which property / array keys are expected to be missing, such as: $foo[?'maynotexist'] // returns null and emits no warning Down the line this might allow us to fix up arrays as well, but that's a question for a different RFC. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Property Error Promotion
On 06/04/2022 17:34, Marco Pivetta wrote: Perhaps worth mentioning that magic methods keep working? Good call. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Undefined Property Error Promotion
Internals, Part 2 of the undefined behaviour improvements, this time focusing on properties. https://wiki.php.net/rfc/undefined_property_error_promotion This RFC draws heavily from the just passed undefined variables error promotion RFC, and is intended to compliment both it, and the 8.2 Deprecate Dynamic Properties RFC. The arguments in favour are the same as the last one, reading things which don't exist will often lead to the program entering an unintended state, and is likely the result of a programming error. There is a difference though that we do explicitly provide an object that is designed to be dynamic, and that is stdClass which is the typical output from json_decode and array to object casts. I would expect we might want to discuss special-casing the accessing of properties on stdClass and leave them as a warning. However, I personally think that for the sake of consistency we should make undefined properties throw across the board, including stdClass. We already have fully backwards compatible mechanisms built into the language (isset, empty, null coalesce, property_exists) to safely handle cases of the property not being defined, even on objects that do not have a fixed structure. I was originally going to include a section for discussion about potentially using AllowDynamicProperties to pull double duty, allowing reads without an error as well, but I do not believe that would be in the best interests of the language, and so removed it. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Undefined Variable Error Promotion
On 14/03/2022 17:18, Mark Randall wrote: I have started the vote for promoting undefined variable access to throw an Error exception. The vote will run for 2 weeks until March 28th 2022. https://wiki.php.net/rfc/undefined_variable_error_promotion The RFC has passed with 33 votes (80%) in favour and 8 against. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion
On 16/03/2022 09:17, Christian Schneider wrote: Maybe we should ask ourselves the question: Why would the entire package be blocked? Just because it is too big or maybe there *are* subtleties which have not been properly resolved? It's politics and the practicalities of getting things done. An all-or-nothing approach will inevitably end up with nothing, because those who are opposed on principle need only rally around attacking the weakest element, without the need to address any of the other parts which might individually be much stronger. That's not to say that the weakest elements shouldn't be debated, they should. But we shouldn't sabotage ourselves, and bring about a state of permanent project paralysis, by mandating that semi-related weaker changes are bundled with stronger ones and must be voted on as a whole. It would just open the door to the constant use of a poison pill argument. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion
On 15/03/2022 23:02, Patrick ALLAERT wrote: I am not against the fact this warning becomes an error per se. I am just not very fan of cherry-picking an individual kind of problem (read: notice/warning/error/...) and changing it without a more global frame. I think we should try to hit all of them, ideally in time for PHP 9. That was the premise behind: https://externals.io/message/116918 It will likely take several RFCs until we've got it in the state we want it, some of those are more contentious than others (such as undefined array indexes). I think undefined property access should throw too, and will likely have supermajority support, but let's do it in a separate RFC. What I don't think we want is the entire package being blocked because a particular item (i.e. array keys) is contentious. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion
On 15/03/2022 19:32, Sara Golemon wrote: What I'm hearing is that we also need an RFC for promoting 'Undefined index...' warnings to Errors as well. We do. If it would pass or not is another matter, it would need someone braver than I to take it up. I think there's some other engine stragglers, e.g. foreach must be type array|object comes to mind, that should really be an exception, maybe array to string conversion too. Who knows, maybe PHP 9 can be the version that removes remove *all* warnings from the zend engine. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] Undefined Variable Error Promotion
I have started the vote for promoting undefined variable access to throw an Error exception. The vote will run for 2 weeks until March 28th 2022. https://wiki.php.net/rfc/undefined_variable_error_promotion Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Question: What are requirements for having (new/old) functionswithin PHP core? :)
On 07/03/2022 12:56, Thomas Krüger wrote: Or if it has nothing to do with performance, why not including everything from PECL into PHP core, so PHP could offer out-of-the-box more and more features for developers? PECL packages get to maintain their own release schedule, unlike PHP which follows a fixed cycle. PECL packages have their own permissions, unlike PHP which only allows a narrow group to merge code into it. The PHP core team does not have the knowledge or time to maintain every PECL package, or even a large number of them. Things distributed in Core should be produced and tested to the same standard as the engine itself. Certain PECL packages conflict such as if they were forked. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 01/03/2022 00:36, Craig Francis wrote: And because I'm back to tired pissed-off sarcasm masking depression (why bother spending days on a solution that works for everyone when we can make a hostile/elitist environment/language)... maybe we could simply suggest that everyone affected by this should use strval() for everything? People aren't giving you the responses you want, because you haven't yet made an argument to convince everyone that your proposed solution is better than the existing ones, which are to use the language's existing tools to provide a sensible string default where one is required. You see a problem, but rather than trying to fix the underlying cause, you're proposing making changes at other layers to accommodate the side effects of the original problem. That is practically the definition of a hack. Except rather than a short term fix, you're proposing to make it a permanent part of PHP. That goes against what many of us would consider in the best interests of PHP and its users in the long term, and yes, we acknowledge that getting to that point will first require some short term pain for those who have historically been overly lax with their coding standards. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 28/02/2022 01:46, Craig Francis wrote: Personally I think `strict_types=1` is fine for my code, but I would never want to force that style on everyone, because doing so would be fairly hostile for a language that's popular and well known for being easy to use/learn. Magically coercing things and hiding things under the hood is useful for the first 10 minutes of learning. After that it just becomes a hindrance difficult because you have to know all of the secret rules about type juggling. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal for RFC to remove undefined arrayindexwarning when used ina ternary
On 27/02/2022 09:12, Robert Landers wrote: I'd also venture that this warning has caused more harm than good, in that writing "$var['something'] ?? null" is second nature when writing new code, even if there is practically no chance for a non-existent key. Using null coalesce should only be used when you know you have the possibility of a missing key. For everything else you've probably entered an unexpected state and should display a warning (that should ideally be picked up by an exception handler and convert it to an exception). When handling external data it is usually a good idea to use a validation step before using it, such as JSON schema. An even better idea is to parse it into a specific type, rather than just validating it, at which point you're going to be using a lot of isset, null coalesces, array_key_exists, property_exists etc anyway and sucking in some default other than null is almost always the wrong thing to do. As to your final point: PHP internals voted by a supermajority to raise this from a notice to a warning in PHP 8, it seems unlikely that 33% of people are now going to change their mind and vote for the opposite. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal for RFC to remove undefined array indexwarning when used ina ternary
On 26/02/2022 22:34, Robert Landers wrote:
This is not semantically the same though. A $_POST of a form, for example,
will usually contain an empty value if the form input was empty, but
missing if the form control wasn't in the form (maybe the form control is
injected via Javascript, or conditionally output by the script).
PHP is a general purpose language, the behaviour you're asking for is
specific to one use case and may be of detriment to others, without
offering significant benefit in exchange.
I suggest you write yourself a function that performs the operations for
you. This may also be a good opportunity to move away from directly
accessing the superglobals in userland code.
$form->get('foo', 'defaultgoeshere');
Performance concerns would be so so small they would be practically
undetectable in the context of a real request.
Also, this:
$name = empty($_POST['name'] ?? 'Default Name') ?: 'Default Name';
Should be:
$name = ($_POST['name'] ?? null) ?: 'Default Name')
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Proposal for RFC to remove undefined array index warning when used ina ternary
On 26/02/2022 09:09, Robert Landers wrote: I'd like to propose and implement an RFC that would consider dropping the warning if and only if array access is the only test in ternary and short ternary (?:) operations but first I'd like to start a discussion to see if it is worth pursuing. I'd like to target PHP 8.2 or 8.3. The warning comes from the array key being missing, not from being empty. There are many values which are empty which do not emit the warning. If you want to provide a default should the array key be missing you want null coalesce. $x = $array['foo'] ?? 'somethingelse'; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 24/02/2022 02:31, Bob Weinand wrote: However, should your RFC pass, it is not possible to say "hey, I generally consider this a low impact class of errors, please try to continue". This is correct. As the custodians of the language, it is our responsibility to decide what the engine considers low / high impact and act accordingly. In some cases users get the choice, but in most cases we make the choice for them. We have internals and the voting system precisely for this reason, to have a broad number of voices involved in those decisions. If users wish to use the latest versions, they must ensure they meet its requirements, this is really no different than any other BC break we do for the good of the language and its users. A couple of years ago we voted to promote 13 things to become errors / type errors, and I note you voted in favour of 12 of them, without requiring an opt-out. I must therefore assume you consider the use of undefined variables to be a legitimate coding style, and that's fine if that is your position. This RFC boils down to internals deciding, as a group, that it isn't one we want to support in future. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 19:32, Rowan Tommins wrote I think that wording change should be part of the proposed change in the RFC. Otherwise, a lot of people simply won't know the decision to remove it has been made and will be surprised when 9.0 comes around. It is already part of the RFC within the "proposed PHP versions" section. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 18:02, Nicolas Grekas wrote: I mean in addition yes, deprecation before warning. I don't see this happening. An engine warning is as stark a mechanism as we have available that you either made a mistake, or shouldn't be doing something, without preventing you from actually doing it. It may be that in 8.2 if this RFC passes that message will change to include "This will throw an error in PHP 9", but giving multiple messages for it is not beneficial IMO. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 11:23, Rowan Tommins wrote: - undefined array keys - undefined object properties - array access on a non-array - property access on a non-object I'd encourage those to be discussed, but they are unrelated to this RFC. I think most of them would pass fairly easily, but undefined array keys is out the outlier and has a reasonable chance of being rejected at this time. However, with their being 4 years before the launch of 9.0 (and the next opportunity to change it) opinion may change between now and then. I've updated the RFC to define accessing a variable as attempting to read its value for use in an expression without accounting for the possibility of it being unset. I have also included the warning message to narrow this down further, and noted that things which account for undefined variables such as isset, empty and null coalesce will remain unaffected. If there's am existing formal definition someone wishes to contribute, I'd be happy to update it. One thing maybe worth mentioning is that while most operators such as ++, +=, .= etc will be covered by this change, $undefined[] = 1; will not be. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 22/02/2022 09:15, Nicolas Grekas wrote: I very much call for an implementation to be provided before starting any vote on the topic btw. The RFC states on its first line that accessing an undefined variable emits an E_WARNING. If it does not currently emit an E_WARNING then it is out of scope of this RFC. It is not sensible to provide a full implementation for something that will require extensive engine and test changes for something several years into the future, during which many other changes will be made. A sensible time for this would be after the branch is cut for 8.4. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Setting to disable the "Undefined array index" warning
On 21/02/2022 10:29, Nicolas BADIA wrote: and I don’t find the code more readable. Here are some examples of changes: The example changes you provide are what many people here would recommend as good practice to improve the context and safety your code provides. Anyone looking at that code can immediately infer that there is an expectation that those keys may be missing, with a suitable default provided for if that is the case. The engine can see this too, which avoids it emitting warnings. It takes a little more code, yes. But that is because you're being more clear in your intent. This is a good thing. You should keep at it. You could probably have the majority of your codebase converted before you could even hold a vote. Even if the vote was passed, which seems most unlikely, you would still need to wait 10 months for 8.2 to come out to use it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 10:50, Rowan Tommins wrote: Other than an optimised implementation, there's nothing particularly special about the ++ operator's handling of null, it behaves the same as any other arithmetic operator: I would claim that the unary operators behave slightly different, if it were a case of cooerce to zero, the behaviour of null++ and null-- would be expected to be the same as operating on 0, but it's not. null++ is allowed, but null-- returns null, and its value afterwards is null. https://3v4l.org/Bnb2D If anything, it's the fact that $a++ is NOT a special case that means it will be affected by this proposal. It is intended to be affected by this proposal. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 07:48, Robert Landers wrote: Just out of curiosity, why is the 3rd case being included here? Is it just because it's currently a warning > When I first taught PHP in 2011, I was told > post-increment/decrement was sugar for `isset($var) ? $var + 1 : 1` This is not the case, there is no isset($var) involved - specficially isset($var) would first check if a variable exists and is not null (ISSET_ISEMPTY_CV), it is designed to handle undefined variables, where as most things are not. Before the increment can happen, the value in the variable must first be read. This leads to the E_WARNING for accessing an undefined variable just like any other, which this RFC seeks to prohibit. The value is then copied internally, the original value is incrementeted, and the unchanged copy is returned (its value before incrementing). The only reason this works at all is because an undefined variable read falls back to null, and the increment operator is hardcoded to treat null++ as 1. That's why if you do this: $x = $foo++; var_dump($x); You get: Warning: Undefined variable $foo in on line 3 NULL Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Undefined Variable Error Promotion
Internals, Following on from my previous thread, I think we are now in a position where we can begin formal discussions on an RFC to promote undefined variables to Error exceptions in PHP 9.0. I present: https://wiki.php.net/rfc/undefined_variable_error_promotion I still intend to bring other error promotions forward, potentially in collaboration with other developers, but as this is the biggest change, and the most likely to attract a large number of comments, I thought it deserving of a standalone RFC. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Setting to disable the "Undefined array index" warning
On 15/02/2022 12:31, Nicolas BADIA wrote: As I’m not ready to spend weeks upgrading our codebase because our coding style is not supported by the community, I’m looking at alternatives. I don't think you'll be in luck, and should plan to get ready. As to the specific behaviour: If anything this behaviour will get tighter over time, and it's entirely possible that in a later major release it will throw an error (although that's not being proposed right now). From my conversations, there is little apetite to add additional INI based controls for engine behaviour, as they are believed to lead to inconsistencies that harm the ecosystem, rather than enhance it. Forking PHP to avoid resolving ambiguities in your code seems like it would be a false economy. Ideally you should bring your code up-to-date with what is expected, but if you are unwilling or unable to do that, you may instead wish to stay on an older version that hax more lax behaviour, and purchase LTS from the likes of Zend. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Pre RFC - __debugType() magic method
On 09/02/2022 13:49, Robin Chalas wrote: What do you think? It sounds like you need to wrap get_debug_type rather than introduce a magic method into core to account for framework oddities. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 07/02/2022 15:34, Craig Francis wrote: So are you suggesting that all the frameworks should change their default to an empty string? or every single project should update every use of these input functions to always override this default, or cast the received value to always be a string? all to avoid a Fatal Error if a NULL value ever dared to be passed to `htmlspecialchars()` and similar functions in PHP 9? I'm suggesting that every project should be specifying the default they want when they call the function. If by omission you call a function in a way that effectively says 'give me a null', then don't be surprised if it breaks when it gives you what you asked for and you pass it to something that wasn't designed for it. Special casing things is almost always the wrong approach and will lead to pain in the long run. Like "0" being the only non-empty string that's falsey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 07/02/2022 12:05, Craig Francis wrote: And specifically with NULL, strings in C are a "one-dimensional array of characters terminated by a null character", so you could say that NULL is very similar to an empty string - maybe that helps address the "pretend its a string" objection? In this case we're talking about the difference between a char* that points to a 1 byte buffer containing '\0' and a char* that itself points to NULL. Trying to perform string operations on a null pointer in C would equally blow up. With regards to your framework comment, any framework worth its salt will also have the option to provide a default value other than null when the value is not provided. It is the responsibility of the user to make use of this functionality to provide the correct type for what the soon-to-be-called function is expecting. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 07/02/2022 01:27, Craig Francis wrote: I know one person simply said this was a "terribl > idea", but I'm still waiting to hear any details on why. The changes you propose are not something that I am comfortable with either. I understand your motivations in proposing them, but to my mind it goes against the direction that PHP is developing, which I think is the right one, where errors and likely errors result in stopping execution rather than allowing it continue, potentially silently (dependent on error handling settings). If a parameter expects a string, that is what it should be given, and its the callers' responsibility to ensure that is the case. If they fail to do so then it's an error just like any other. IMHO reverting to "If it's a null we'll just pretend its a string" is contrary to how the language should be progressing. It sucks that it was ever allowed in the first place. PHP has a long history of making descisions to try to make things 'just work', and if history teaches us anything, its that we inevitably come to regret these descisions down the line. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On 29/01/2022 16:33, Christian Schneider wrote: If a static analyzer manages to catch it at development time then that is a lot better. Of course it's better, but you wouldn't argue that a car doesn't need airbags because you've tested that the breaks work. Defense in depth. Our ecosystem of static analysers are fantastic, but they're standalone tools outside the remit of internals. Maybe that software has a bug, maybe it hasn't yet been programmed to recognise the side effects of a new feature that was added, maybe the user has not updated the library in a while. With runtime checking, the engine should always try to protect against the unexpected, irrespective of if other checking has already been performed by outside sources. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On 27/01/2022 22:09, Larry Garfield wrote: I am not sure what additional value is gained by making the scream even louder. For us to make something an exception at engine level, is to stop execution on the grounds that the engine no longer considers it safe to continue. That might be because a boolean was passed to a function that expects a string, or in this case it might be because an undefined variable has been read. Notices / Warnings are irrelevant to this under the default configuration, as in the absense of a userland error handler the engine will happily allow code to continue executing even after a probably undesirable state has been detected. So what we're talking about here is changing the engine's definition of what is safe to exclude read operations on an undefined variable. I understand the argument that the behaviour is well defined, at least for some operations, but I would posit that the vast majority of reads on undefined variables are in fact unintentional side effects from branching logic and are not the real intention at all. If someone is insistent on working with nulls, there is an easy to use, fully backwards compatible way to avoid these errors, which is to define a variable as null prior to any branching logic. For everyone else, we should offer this entirely sensible safety net. What we don't want to do, I think, is end up in a situation like JS where it has to be opted in: https://www.w3schools.com/js/js_strict.asp -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On 26/01/2022 14:48, Christian Schneider wrote: Please don't flame me, I just wanted to point out that there is an opposing view on internals to consider ;-) It is my firm believe that a language such as PHP should not be dependent on static analysers to protect users against engine-level problems that may occur during runtime. Third party static analysers are great, and I am a strong proponent of Psalm. However, internals is not responsible for getting people to use a static analyser, we are responsible for the behaviour of the engine, and right now the engine is, I think, too lax in this regard. We should be aiming to provide a reasonably safe experience out the box. That you're manually patching PHP to change official behaviour (which was passed by RFC) puts your individual use case well outside of what should be considered when voting. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On 26/01/2022 17:13, Rowan Tommins wrote:
For instance, the following code is safe, useful, and readable:
$countsByDayByCategory = [];
foreach ( $someData as $item ) {
$countsByDayByCategory[ $item['day'] ][ $item['category'] ]++;
}
I myself am not planning to hold a vote on undefined array.
If there were one it would be an independent vote the same as "Undefined
Array Index" in https://wiki.php.net/rfc/engine_warnings which promoted
it to warning in 8.0.
As it's marked as a warning, I would expect it to still get upgraded at
some point in PHPs lifetime, maybe even in PHP 9, but I am not proposing
it with this batch of updates.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
Internals, PHP 9.0, likely a few years away at this point, is our next opportunity to make significant breaking changes. So I thought it would be appropriate to start a thread discussing what breaking changes we might want to include in it, specifically in relation to error handling behaviour both at engine level, and potentially library level. By discussing and passing RFCs sooner rather than later, end users and library maintainers will have much more advanced notice than if we waited until 8.4 had released. My goal is to help coordinate putting forth a set of individual RFCs, or maybe a collective set similar to https://wiki.php.net/rfc/engine_warnings that will specifically target PHP 9.0, even though that version does not yet have a release date, or even a release year. Nothing in this conversation will preclude others from passing additional RFCs in the future years that also target PHP 9 error promotion, or, for that matter, reversing those decisions potentially made here, if necessary. For my part I will be putting forward two votes which will hopefully complete the migration process started in Nikita's engine warnings RFC: ** Undefined Variables Promoted to Error ** PHP currently treats reading an undefined variable as though it were a null, emitting a warning message in the process. This was previously promoted from a notice in the PHP 8 engine warnings RFC. At the time a 3 way vote was held between promoting to an error exception, a warning, or leaving it as a notice. At the time, 56% voted in favour of throwing an Error, 28% in favour of a warning, and the remainder leaving it as a notice. My understanding is that many of those who voted to raise it to a warning did so because they felt that jumping straight from a notice to an Error was too much in one go. As it will have been a warning for around 5 years by the time PHP 9 is released, I expect that there will now be a healthy super majority to bump this up to throwing an error. ** Redefine Constants Promoted to Error / ValueError ** Attempting to redefine a constant either via 'const x' or define currently emits a warning, as well as failing. My straw poll (https://wiki.php.net/redefine_constants_exception_strawpoll) gives a strong indication that there is an appetite to promote this from a warning to an error, potentially throwing a ValueError, in PHP 9. This will bring it more into line with the result of attempting to redefine other constructs such as functions and classes. ** Other Recommendations ** Let's open a discussion as to what we might want to do in the future, and depending on how things shake out, we can decide what route to take with regards to bringing RFCs to vote. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [Strawpoll] Promoting redefining constant to exception
Internals, While cleaning up some PRs I was prompted to re-visit one I had outstanding about exception-throwing behaviour when redefining constants, this applies to functions like define and language syntax constructs such as const. There have been a few discussions in the past about the topic. Here is one from 2016 from Dmitry: https://wiki.php.net/rfc/constant_redefinition Discussion: https://externals.io/message/93885 My own PR: https://github.com/php/php-src/pull/5265 Since Dmitry's RFC was made in 2016, and my PR a while ago, attempted redeclaration was promoted from a notice to a warning, but I still think it's sensible to go one step further. There was mention on github that there was some resistence to promotion to exception in the past, but I think there is a strong possibility that the mood may be different many years later, with PHPs positive moves towards throwing on poorly defined or illogical behaviour. To gauge this, I'm throwing out a non-binding strawpoll to get the lay of the land before doing anything else with it. If there is general favour I'll fix up my patch and do a proper RFC. https://wiki.php.net/redefine_constants_exception_strawpoll Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Allow default parameters before non-default ones?
On 09/12/2021 05:22, André Hänsel wrote: This is very useful because I can add an optional parameter to a function and prevent users of my function from using the parameter in a positional way. This way I don't have to make a compatibility promise to never change the position of this parameter. I would much prefer we could find a way to give this proper support rather than a hack. I frequently use large numbers of named arguments and would very much like to be able to knock out the ability to use positional arguments, thus ensuring I can change the order (e.g. inserting a new argument after a related one) without a BC break. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion] array_column results grouping
On 05/12/2021 14:02, Rowan Tommins wrote: Since this is explicitly an open question in the current RFC draft, it seems a bit premature to talk about voting, rather than encouraging the RFC to develop in a particular direction. I hope it was taken as nothing more than an indication that adding an extra argument to array_columns would not be our preference for the route to go down :-) I could see the benefits to a standalone array_column_group function, that way the expected dimensions of the output would be more easily recognisable without having to inspect the parameters. As this RFC focuses heavily on array_columns, including all of the examples and the PR, I would encourage the author to consider an RFC specifically for array_column_group. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion] array_column results grouping
On 04/12/2021 14:21, Marco Pivetta wrote: Gonna vote `no` on this: please design new/dedicated functions, rather than expanding optional parameters. I would vote no for the same reason. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Deprecate dynamic properties
On 15/11/2021 23:35, php-internals_nos...@adviesenzo.nl wrote: Either way, in my estimation, handling this deprecation will - again - require not insignificant dev-time from maintainers to determine the best course of action for each flagged instance and to implement the changes, and what with the stagnation in OSS already happening, I wonder if now is the right time for adding this to their work-load, especially with the relatively flimsy argumentation for this RFC. Can you approximate how much time you expect this to take? Adding #[AllowDynamicProperties] to the top of each class seems like it is unlikely to be something that would take much time, and will almost certainly be catered for by automated tooling such as Rector before too long. Even without such tools, it could be applied by hand to hundreds of files in under an hour. Do you have a reason this is not the case? Of course, the downside to this is that by doing so it may cover up existing bugs that this change is meant to help identify. A distinction must be drawn between changes that MUST be made to be compatible, and changes that SHOULD be made because your code is carrying tech debt. I would be interested in hearing how much of the workload you are experiencing falls into each category. ... To cover the other point which is more subjective: The inability for certain open source projects to keep up should absolutely not be a reason for PHP to slow down its development. While OSS library projects are certainly important to the ecosystem, they represent a tiny fraction of the code that is written, and are often constrained by a small number of contributors to work on them, often times only a single person. Should millions of other developers be held back because of the weak foundations of certain OSS projects? I think to do so would be a collosal mistake. Yes, that means that some of these projects will not be able to do what's necessary and will fall into disrepair and be abandoned. I personally consider that an acceptable loss when compared to all the benefits these changes bring. We must look to the future, for every line of PHP code that has ever been written, it's likely that there will be hundreds if not thousands of additional lines that will be written in the future, many of which will by people who have never written a single line of code before, in any programming language. For that reason it is essential that PHP's out-the-box experience is sane and safe(ish) by design, and that means that common-sense defensive coding mechanisms should be the default, not something that you have to opt into, even if that means that old code will need to be modified to be compatible with those measures. To do otherwise would be entirely unethical. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Nullable intersection types
On 23/07/2021 10:58, Nicolas Grekas wrote: Hi everyone, I wrote everything down about the reasons why here: https://wiki.php.net/rfc/nullable_intersection_types IMO we should require brackets and forbid not using them when combining unions and intersections. These types are already going to be confusing enough and we can likely save a fair amount of confusion and pain down the line by requiring the explicit brackets. Without wanting to bikeshed, let's just make sure we're set on () because whatever we choose here will be the defacto mechanism for declaring sub-types in PHP for the rest of eternity so it would need to be maximally compatible with everything we might want to do with them. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd
On 06/06/2021 14:00, Ben Morss via internals wrote: Thank you for these comments! Perhaps it would make sense to, at some point, create a followup proposal to namespace the entire gd extension - so that all gd functions would be in the namespace? I'd leave it to others to determine whether this would be desirable, or whether it wouldn't be worth making developers update existing code. When we de-resourcified Gd we considered making the Gd class be useful as something more than an storage type. If doing a full remap it may be worth putting the functions into the class itself. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Disable autovivification on false
On 05/06/2021 20:50, Kamil Tekiela wrote: However, I would still like to hear from you whether you use autovivification from false and/or null in your projects. So far, I was not able to identify when this would be useful in real-life scenarios. As per the RFC: "In PHP 8.1, appending to a variable of type false will throw a deprecation error" You might want to clarify this language, throwing an error is understood to have a specific meaning in PHP, and it's not what it's doing here. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Partial function application
On 25/04/2021 20:25, Larry Garfield wrote:
It includes an implementation by Joe Watkins that is already about 95%
complete. (There's some edge cases he's still sorting out, but all of the
typical cases should work already.) Most of the design work comes from Levi
Morrison and Paul Crovella. I helped out with the tests, a few edge bits, and
general instigator/nudge. :-)
Can I be a little pushy and ask for a subvote on "..." vs "...?"
It _probably_ won't matter, but with ... being used as the language's
universal variadic / unpack, we may use it for similar things in the
years to come, and I think it makes sense to pre-empt a potential
conflict or source of confusion down the line by using "...?".
Just as a variadic function argument is ...$ a variadic partial closure
would be ...?
I do not, at this time, have a firm example of where this might become a
problem, otherwise I would state it. The closest I can think of for now
is that it's entirely possible that auto-capturing multiline functions
may end up using:
$x = function() use (...) { /* */ }
Which could possibly be confusing. Not a definiative example by any
stretch, but but I do get the feeling that, as we can future proof it
for effectively zero cost, we should.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] A little syntactic sugar on array_* function calls?
On 28/05/2021 15:31, Nikita Popov wrote: This is a more complex case. In this case the compiler doesn't know in advance whether the argument is passed by value or by reference. What happens here is: I'm trying to wrap my head around this, but if a function arg can handle this, does something internal to the engine preclude fetching in write context, after already fetching in read context, other than performance? So can the initial fetch be performed with FETCH_DIM_R, handling the object case + any other scalars, and if and only if the value is an array and operating on what would traditionally be a by-ref, repeating the previous lookup with FETCH_DIM_W? Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
On 15/05/2021 01:00, Larry Garfield wrote: I can't speak for the others, but I could tolerate making "more than one extra ? beyond the end of the parameter list is an error", potentially, as at that point they're redundant. But if a function has, say, 4 params, then fourParams(1, 3, ?) is a convenient way to say "and placeholder everything else". Fortunately, we already have an existing and recognised way of saying "and everything else" https://www.php.net/manua/en/functions.arguments.php#functions.variablearg-list -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial function application
On 14/05/2021 22:48, Aaron Piotrowski wrote: I think it’s reasonable to allow passing more arguments to a partial since user-defined functions and closures allow this without error. But only userland functions, a relic from when func_get_args was the only way to handle varaible numbers of arguments. The documentation officially discourages func_get_args in favour of ...$ so I can definitely forsee the option of us deprecating that mechanism sometime in 8.x and and removing it in 9.0. I don't think it likely that it would go the other way of allowing unlimited arguments to internal functions. That being the case, IMO it makes more sense to introduce partials with the same behaviour as internal functions, passing more functions than specified (including partial arguments) should error. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Partial function application
On 25/04/2021 20:25, Larry Garfield wrote:
Discuss.
There has been intense discussion in R11 about how the ? token applies
to missing or variadic arguments.
The root of the concern is that in the current proposal, ? applies as
either a placeholder for a single replacement, or 0-or-more varadic
arguments, depending on its position and the number of arguments.
I and several others believe that this feature would be better served by
restricting ? to representing a single argument, and using ...? to
represent "anything else" including an empty set.
## To illustrate the scope for confusion:
foo(?) looks like it requires one argument, when in reality it could
accept none, 1, or a hundred.
foo(1, ?) looks like it also accepts one argument, but it could accept
0, or 100, depending on the function it is wrapping.
foo(?, 1) definitely requires at least one argument, but could accept
more depending on what it's wrapping.
## Suggestion
Based on discussions in R11 there seems to be broad agreement that ?
should represent a single argument, and ...? should represent everything
else (including no arguments).
Thus:
foo(...?) - Partial of foo with all the arguments copied over.
foo(?, 1, ..?) - 1 required, then 1 fixed, 0 or more others are copied over.
foo(1, ...?) - Fix the first parameter and copy over the rest.
This can be seen as a mirror to the ... operator that accepts a variable
number of arguments.
function foo($a, ...$b) { }
Equally it matches the syntax for unpacking into arguments:
$a = foo($a, ...$b);
Passing more arguments than the partial defines would result in an
argument count error.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Bugsnet
On 09/05/2021 09:05, Stanislav Malyshev wrote: I don't see how we could "just move" if all our bug handling would be wired into Github. I can easily see how we could move a repo to any provider that supports git - git is a generic platform, Github is just a frontend. But there's no alternative frontend for Github Issues that we could just copy the data into - you move, you lose your existing system. There are probably import tools on some platforms, but the processes, assignments, etc. - all will have to be re-developed, even if we could re-use the raw data. If Github does something so outrageous that a move is required, it is unlikely to just be PHP that is affected. Such an eventuality would be all but certain to result in a huge cross-community effort to develop automated migration tools. Tools such as github already have integrations that allow migrating Github data into their own formats. I personally am not at all worried about having bugs on github. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] wiki.php.net upgrade
On 08/04/2021 19:38, Stanislav Malyshev wrote: I think it's just because nobody has focused attention to it. As you see, once it was focused, it has happened. This is usually referred to as shutting the stable door after the horse has bolted. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Autoloader Classmap
On 15/03/2021 17:41, Mark Randall wrote: I would like to propose the addition of a new mechanism of autoloading classes - a classmap that will be consulted prior to checking the spl_autoload_register'd callbacks. https://wiki.php.net/rfc/autoload_classmap Does anyone else have any more feedback on this? If not I plan on opening voting in a couple of weeks or so. The tl;dr: * Autoloading is one of the routines called most frequently in any request. * It's a very minor boost in autoloading performance, around 5% vs invoking a userland function. This will easily be swamped by any IO and invalidated entirely by preloading. * I expect 99.% of users will never know it exists, and it will instead just be an option for tools like composer that will provide a small transparent boost. * It provides a very minor benefit to debugging as you get to skip over the autoloading frames which so very often come up during a request. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: include vendor/autoload.php automatically
On 27/03/2021 16:52, Abdul Haq Sheikh wrote: - On Index.php, php will automatically include 'vendor/autoload.php' because the vendor directory exists. - On Test.php, php will automatically include 'vendor/autoload.php' because the vendor directory exists. - On Classes/test2.php, since file is in sub directory and here vendor directory doesn't exist, so php will not include 'vendor/autoload.php' Just an observation, but if you're doing vendor/autoload.php from your index.php page, and are not already doing custom include paths, then chances are you have your vendor directory publicly accessible and that is considered unwise. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closuresandshortfunctions take 2
On 25/03/2021 13:54, Olle Härstedt wrote: JS does not support "definitely local". No language does, AFAIK. Unless you count value types. We were both refering to block-level variables, which most languages do. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2
On 25/03/2021 09:28, Rowan Tommins wrote: That's not quite what I meant. I meant that you can't say "capture by default, but this variable is definitely local". I think if there's one argument against, this would be it, but IMHO it is a weakness in PHP as a whole. The solution would be adding JS-like let / const statements. Which would be a benefit to other things too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2
On 24/03/2021 21:00, Rowan Tommins wrote:
As Christian says, automatic capture is a dramatic change to the
language's scoping rules, and IMHO requires a more thorough
justification on why the current syntax is burdensome. As I've said
previously, my naive impression is that a long list of captured
variables ought to be as bad a code smell as a long list of parameters;
I'm willing to be proven wrong on this, but nobody has yet stepped
forward with a real-life example.
Automatic capture ceased to be a dramatic change from PHP the day after
short closurers were introduced. So they've been a part of PHP for years
now.
I hit long lists of use() repeatedly, almost always because I need to
perform a series of operations within a callback, prime examples are
database transactions and using throw-aware buffering handlers.
In general, anything that needs to wrap a code block in a complex set of
instructions before and after.
To give my own example, earlier this week I wrote the following:
$x = function () use ($to, $library, $thread, $author, $title,
$library_name, $top_post) { ... }
That was just to get those variables inside a callback that could be
invoked inside a throw-aware buffering helper.
I believe that by explicitly stating my intent to use auto capture by
using fn() { ... } that my code would have been cleaner with less noise.
If I thought otherwise, I would be under no obligation to use them and
could use function() { ... } instead.
For me auto capture is a solid +1.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Autoloader Classmap
On 19/03/2021 14:45, Nikita Popov wrote: Could you please update the RFC with some performance numbers, including the used methodology? The number of 5% has been floating around, but it's not clear what it refers to. I'm primarily interested in end-to-end effect, e.g. on the symfony demo project. I have updated the RFC with the following: Testing suggests that autoloading through an internal classmap delivers around 5% performance increase vs a userland function call (e.g. composer). This is 5% of the cost of the autoloading, and not the execution as a whole. Testing was performed by creating 50,000 empty classes each in an individual file, and then autoloading every one of them in a loop. Amount of classes was purely to help reduce noise. Average for internal classmap was 0.295 vs 0.313 for spl_autoload_register representing 5.9% difference (in autoload performance only). >> I appreciate this is a small amount. If internals feels the additional code is not worth it for such a small gain, I have no issue at all with the RFC being rejected. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Autoloader Classmap
On 17/03/2021 01:29, Mike Schinkel wrote: Would core not be able to implement an add() more efficiently than a get()/set()? I am especially concerned the get()/set() approach might require allocating memory for the returned array for every get(). There is no good way to add features to mutate the existing array without causing a net performance penalty considering the approximately 5% boost this RFC provides vs a userland function. It is a micro-optimization written exclusively with a single large pre-generated list in mind. It will be left to the voters to decide if 5% of an extremely common operation is worth the few dozen lines of code required. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Autoloader Classmap
On 16/03/2021 14:21, Larry Garfield wrote: 1) As the stated reason for this RFC is performance, have you any benchmarks to show how much we'd win by using an engine-space lookup rather than user-space lookup? Performance benefit is unfortunately quite small, my tests suggest it is in the region of 3 to 5% vs invoking a userland function an equivilent number of times and looking up in a classmap. It's ever so slightly higher if comparing against something doing a lowercase on each one. If that's enough to justify it passing an RFC is left to the voters. The intent is for a free micro optimization at framework level that most users would never see. 3) The lower-casing of class names feels weird to me. Why? Given that most filesystems are case sensitive, that seems like an odd requirement and the RFC doesn't include an explanation of why that's beneficial. The filesystem is case sensitive, but the class names are not, and are handled as lowercase at engine level. new Foo() is the same - new foo() as far as lookups. Requiring lowercase names means that the lookup will perform the same regardless of which case is used in the code. Doing otherwise would require either an exact case match (which is not how PHP operates), or forcing the list to lowercase at the call to autoload_set_classmap, which would harm performance when it's perfectly reasonable to expect a static lowercase map to be given. It is important to note that only the array key is lowercase, the value, the path name, IS case sensitive. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Autoloader Classmap
On 15/03/2021 22:18, Levi Morrison via internals wrote: Like any other case insensitive symbol PHP works with that comes from userland, I would lower it in the engine's side of things. I would not push the lowercase requirement on the API. That was the first design, however it required re-creating the array with potentially many thousands of new strings which slowed it down considerably. As I envisenge this to be used with machine generated data, having it use lowercase would not be an issue. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Autoloader Classmap
On 15/03/2021 17:59, Levi Morrison via internals wrote: IMO, these should be the defined case of the class, or we should be insensitive about it. It's one thing that our symbols are case insensitive; it is wholly another to _require_ it for this feature by requiring lowercase names. I assume there is some motivation for this; I would like to hear it. EG(class_table) is stored lowercase, the case of the class name itself is only known once it has been found which could only occur after the autoloader has run. By forcing lowercase we have a single key to lookup for any variation, without it we would have to either match the case exactly (which would be different from how internals currently works) or would have to iterate over every item in the classmap array each time, performing case a insensitive comparisons on every key until one was found, or in the worst case, the entire set. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Autoloader Classmap
Hi Internals, I would like to propose the addition of a new mechanism of autoloading classes - a classmap that will be consulted prior to checking the spl_autoload_register'd callbacks. https://wiki.php.net/rfc/autoload_classmap Mark Randall marand...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Potential RFC around PDO
On 18/02/2021 03:37, Mark Randall wrote: Long ago, PHP had a similar feature called Magic Quotes. My apologies, I had only that top paragraph visible in my preview and responded to entirely the wrong part of your post :-( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Potential RFC around PDO
On 18/02/2021 00:57, Daniel Beardsley wrote: At iFixit we use a forked version of php with a small change to allow automatically html-escaping echoed strings: https://github.com/iFixit/php-src/commit/cb6eb5c35a07c843e5b357884186d77e3a1a2981 Long ago, PHP had a similar feature called Magic Quotes. It is now universally considered to be among the worst and most damaging features that PHP ever introduced. There is no apetite to reintroduce such a thing. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fibers
On 12/02/2021 21:40, Aaron Piotrowski wrote: I would like to open voting for this RFC around the beginning of March, so please review the minimal API and provide any feedback soon. Removing the scheduler was likely a good plan, but pretty please reconsider your future scope. It's going to be a really big pain to push people to use this functionality, only to have to re-write it 1 or 2 year later because a vastly superior syntax mechanism was introduced. If you can add async / await / delay / defer, even if it takes another month or so, that would likely make this RFC have a significantly bigger and more beneficial impact on userland. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Proposal: namespace the SPL
On 11/02/2021 16:39, Levi Morrison wrote: Let me know what you think. I am hopeful this approach will work because: 1. It is focused on a specific area which already has an established "namespace", but in name-only (not technically). 2. It does not try to solve the larger problem, which has a lot of disagreement. 3. I will be proposing new types for ext/spl soon (`ReverseIterator` and an array iterator that is more efficient than `\ArrayIterator`), and Tyson Andre has already proposed `CachedIterable` and company which is in `ext/spl`, so this space has active development. Thank you for your time. Do you want a dumping ground? Because this is how you create a dumping ground :-) If we're going to start putting things into namespaces (and we should) then we should absolutely avoid repeating the mistakes of the past by dumping completely unrelated things together. If SPL\ is to exist (and personally I think SPL is so cancerous, it shouldn't) then IMO it must absolutely be SPL\iterators. Without that all we've done is swap one problem for another. The idea of putting data structures next to generic iterator helpers is, quite frankly, nuts. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] PHP\iterable\any() and all() on iterables
On 08/02/2021 15:14, Kalle Sommer Nielsen wrote: Den man. 8. feb. 2021 kl. 17.08 skrev Levi Morrison via internals : - I do not like the chosen namespace. This is not as important as the previous point, but still factored into my decision as we are still very early in choosing namespaces for internals. I don't want to vote for something I think is a bad direction when we're this early on. I am voting yes because the functionality is good and the namespace question was polled in advance using the fairest method available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables
On 10/01/2021 16:52, tyson andre wrote: - no namespace: iterable_any()/iterable_all() - iter\ (conflicts with nikic/iter but was also suggested by Nikita) - iterable\ (see below note) - PHP\ (This deliberately uses uppercase, see https://www.php.net/manual/en/language.namespaces.rationale.php) - PHP\iter\ - PHP\iterable\ (see below note) - Ext\Spl\, as suggested in https://wiki.php.net/rfc/php_namespace_policy - Spl\ - Spl\iter\ - Spl\iterable\ (see below note) FWIW as iterables and the likes relate to engine features, the PHP namespace policy RFC would have considered them ideal candidates for \PHP\SubNS rather than \Ext\SubNS Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: "TryX" idom for Enumerations
On 10/01/2021 21:27, Larry Garfield wrote:
The "a method that begins with try is nullable, so watch out" idiom is present
in C# and Rust, but to my knowledge has never existed in PHP. That doesn't make it bad;
it actually combines quite well with the null coalesce operator to allow for default
values, making a valueOrDefault() method unnecessary.
I get the advantages of returning null, in particular WRT the null
coalescing operator.
However, when I see 'try' I instictively think 'exceptions' i.e.
try/catch when the reality is it's the opposite and it would be the
non-try functions which throw.
But it makes sense for those to throw.
However if you will permit me a tangent...
There is an alternative, of sorts. Something I tried investigating when
I first started looking into PHP-SRC, but lack the skill and knowledge
to implement myself.
A shorthand try / catch of something like the form:
( ResultExpr, ...)
At which point tryFrom becomes:
$order = attempt(SortOrder::tryFrom($input), ValueError => SortOrder::Asc);
Which would be the equivilent of:
function attempt(callable $try, array $map): mixed {
try {
return $try();
}
catch ($e) {
foreach ($map as $class => $expr) {
if (is_subclass_of($e, $class, true)) {
return $expr();
}
}
throw $e;
}
}
Or just allow a mixed value to be given without a mapping for catching
Throwable.
If added as a language construct, except each expr and $try itself would
be parsed closure at language construct level to avoid needing to fn()
them all e.g.
$foo = attempt(fn() => SortOrder::tryFrom($input), [ ValueError => fn()
=> null ]);
Just a thought, perhaps a cleaner solution to a wider problem. A try /
catch combined with a match.
It avoids the need for two methods, just provide the one that throws and
use shorthand to assign a null if it throws.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables
On 06/01/2021 14:57, Nikita Popov wrote: Once you introduce an additional meaningful namespace in the form of SPL\iterable\any, you are better off either dropping the SPL part and arriving at iterable\any, or replacing SPL with something more sensible and arriving at PHP\iterable\any. PHP\ModuleOrFeature\Abc was the style listed in the PHP Namespace Policy RFC presented by Larry and I, which was voted down, perhaps due to specific elements of the RFC, or perhaps due to a dislike of namespaces in general. If you believe that PHP\ModuleOrFeature\Abc is a sensible approach to take, then I would implore you to pick up the mantle and try and push everyone towards agreement, lest this keep coming up again, and again. Fortunately, your words carry great weight, and you're likely to be one of the few people who could succeed where so many others of us have tried and failed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Straw poll: Naming for `*any()` and `*all()` on iterables
On 19/12/2020 20:24, tyson andre wrote: Hi internals, I've created a straw poll for the naming pattern to use for `*any()` and `*all()` on iterables. https://wiki.php.net/rfc/any_all_on_iterable_straw_poll These functions make sense. However I think we need to give renewed consideration to: $itr->all(); $itr->some(...); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: strict_types will be default at some moment?
On 11/11/2020 20:20, David Rodrigues wrote: If yes, what is the reason for requiring it? Why it can't be the default behavior (or maybe, the unique behavior). There was some discussion around the idea of adding language editions to PHP for 8.0, however the pandemic resulted in to the in-person conference that would have discussed it being cancelled. If that ever goes back into discussion, I think that I and many others would argue that strict_types=1 would be a baseline requirement of the first edition. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables
On 01/09/2020 16:05, Levi Morrison via internals wrote: Anyway, the key point I'm making is that I think a larger RFC has a better shot of passing if we want to namespace it. Try as we might 4 of us working together couldn't get namespaces accepted. I got the feeling that there seems to be an opposition to them on principle, rather than the merits or drawbacks of the RFCs. Various libraries do use statics for this: Iterators::all() -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Should hash comments be deprecated?
On 21/08/2020 18:28, Theodore Brown wrote: Since the #[] attribute syntax is currently winning the vote, [1] it makes me wonder if the use of comments starting with # should be deprecated. I've mentioned this myself in R11 a few times and was planning on bringing this up to a vote myself as soon as we started for 8.1 I think it makes perfect sense, there's no reason why we need both // and # and if #[] wins out as it looks like it will, that's even more reason to deprecate #. There's an easy upgrade path too with a perfect substitution, and so far as I can tell the only breakage would be if people were using external code to do pre-processor like operations such as using #start and #end as quasi-tags. Ideally, if we pass #[ ] we would deprecate # in the same version and put it on the fast-track to removal, but that would require an additional vote. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Feature Request: dependencies container
On 03/08/2020 04:31, 3u93n3 wrote:
The main idea is to take control over objects creation and injecting
dependencies.
Hi 3u93n3,
Thank you for the effort. However, it is generally accepted that this
kind of functionality belongs to userland rather than the core.
There are a few issues with this proposal:
1. It depends on global state (register_dependency_bindings) which is
something we aim to avoid as in the vast majority of cases it leads to
unfortunate outcomes and difficulty in maintaining code.
2. It introduces more language magic, and sentiment is generally against
more magic.
Most of all though, this problem has already been solved in userland by
instantiating objects via factories - no magic involved, just static code.
With (presumably) 8.0 and the introduction of attributes, existing
dependency injection frameworks will have additional methods of cleanly
expressing which constructor fields are injected, and which are user
supplied.
We might even expect that these frameworks will be updated to take
advantage of this and include automatically generated factories:
#[Service]
class Foo {
public function __construct(
#[Inject] Foo $foo,
#[Inject] Bar $bar,
string $value
) {
...
}
}
$container->factories(Foo::class)("value");
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On 28/07/2020 22:55, Theodore Brown wrote: I appreciate the examples. I think there are good reasons not to implement these kind of extensions, at least in this form. I'll reply to each example below. The problem is your argument comes from a position of... because you don't like those examples, we shouldn't make accomodation for them or anything like them in future. Adopting such extensions is a matter for a future RFC, and not for preemptively throwing a spanner in the works. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On 28/07/2020 18:57, Theodore Brown wrote: Having a closing ] makes it easier to extend Attributes with more syntax This might be a good argument if there were actually a need to extend attributes with more syntax. What other languages have found a need for this? Even Rust doesn't allow additional syntax inside the brackets. Just because they haven't, does not mean we won't. Unless there's a good reason to do otherwise, we should provide for future flexibility where possible. I previously provided examples of ways in which we might want to extend the syntax. Most things in PHP allow some level of scope restriction, such as private or protected. One day we may want to extend annotations to include such a feature, such as a protected annotation that can only be accessed by the class itself or its descendants. #[protected MyAttribute(xyz)] Attributes are not validated when they are encountered, this may be something that we wish to allow attributes to opt-in to in future. #[checked MyAttribute(xyz]) In future we might want to offer APIs that return an array of all of the instances (moving the creation up from newInstance) and then tighten up the behvaiour for classes which do not exist (because they might belong to an optional package, such as debugging or code analysis). This might come in the form of something like: #[optional MyAttribute(xyz)] Some of these might happen, none of these might happen, something completely different might happen. What is clear is we've got to support Attributes for 20, 30 years, and we should leave the door open for easier and cleaner syntax additions if there's no compelling reason not to. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [Vote] PHP namespace policy
On 26/07/2020 17:24, Larry Garfield wrote: The vote on the PHP namespace policy is now open: https://wiki.php.net/rfc/php_namespace_policy Thanks to Larry for putting in a lot of effort with this RFC. I would like to think this RFC provides a solution to a legitimate long-term problem. 1. It will allow the logical grouping of related classes and symbols within namespaces, as is considered best practice in userland. So far as naming goes, there is no reason to believe what is applicable to userland is not equally applicable to php-src and its extensions. 2. It will prevent us needing to "fake" namespaces by prefixing future symbols with Php or the extension name. 3. It provides for bundling and unbundling extensions without the need to change symbols. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: The @@ is terrible, are we sure we're OK with it?
On 22/07/2020 13:00, Derick Rethans wrote:
- There are lots of grumbles, both on here, room 11, as well as in the
wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
From discussions in R11 I want to offer the following example of why
either option with a closing tag is preferable to allow maximum
flexibility in future development.
Assume we want to extend attributes to include something a lot of PHP
features have, an access scope, to only allow accessing annotations from
within the class itself, or a descendant.
Then we end up with something like :
class Foo {
@@protected Attr protected int $bar;
}
Contrast that to something with opening and closing tags where they are
clearly grouped:
class Foo {
#[protected Attr] protected int $bar;
}
What other syntax might we want to add? Perhaps we want to add a way to
enforce validation at encounter time with a "checked" keyword.
@@checked protected Attr(1,2,3) protected int $bar
#[checked protected Attr(1,2,3)] protected int $bar
It's much less ambiguous what belongs to what.
Now we could dig ourselves out of this hole using additional tokens
around @@ such as @@(checked protected Attr) but at which point why not
just use a mechanism that supports it out of the box?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
On 23/07/2020 08:02, Côme Chilliet wrote: To be clear, is there anyone who voted for @@ and changed his mind based on new information? Please see the initial discussion here: https://externals.io/message/110568#111038 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
On 23/07/2020 02:00, Sara Golemon wrote: Regards the vote; I don't believe that @@ has been proven unworkable, however if I'm wrong about that, then the second choice selection from the last vote would obviously take precedence. I don't believe the concern is that we have something unworkable sitting in front of us right now, after all if that were the case we would not be needing to have this conversation as the RFC would already have been rendered void. What we do have, is a deep sense of unease that we collectively made the wrong decision, based on, in part, incomplete information. While the initial block to @@ has been remedied by a larger language-level change, that the problem existed at all provided a clear example of the widely unforeseen challenges associated with the @@ syntax and its lack of closing tags, and focused renewed attention on long-term consequences which where perhaps not given enough consideration during the vote. There has been one occurrence already, there will likely be more in the future. But what specifically will they be and how severe? We likely will not know until they happen. But what we can say with reasonable confidence is we have an option on the table that is technically superior, has an implementation ready to go, and that will significantly allay the fears of many in internals who feel that the @@attributes syntax poses an unnecessary risk of burdening future development. Lets' not commit ourselves to 20+ years of supporting a syntax that we already have strong reservations about before it's even out the door. Mark Randall marand...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
On 22/07/2020 17:43, Dik Takken wrote: That means we effectively disregard the preferences of the ones who voted for the @@ syntax. We do not know what the @@ voters would have chosen if the choice was between << >> and #[]. In case the @@ voters have a preference for << >> the result could turn out differently. The only way to know is to take another vote. Yes we do - it was a ranked choice vote where voters selected their first, second and third preferences. If @@ is eliminated, the second choice of all those who voted for it as their first choice is already known. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: The @@ is terrible, are we sure we're OK with it?
On 22/07/2020 13:00, Derick Rethans wrote: I know we've voted twice on this already, but are we really sure that the @@ syntax is a good idea? No, no we are not. We've already found one gaping hole in it, we will likely find more. Why knowingly back ourselves into a corner when there are perfectly good alternatives? Mark Randall marand...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 20/07/2020 16:58, Michael Wallner wrote: Distilled down, I just cannot see any huge benefit out of a (or two) root namespace(s). As a project we rightfully own the root namespace, and putting everything beneath PHP just doesn't make any sense to me. You cannot just "own" the root namespace if you want to use namespaces yourself, which we will, it's inevitable, the number of classes and interfaces increases more and more each release. So either you fake namespaces e.g. PhpToken or you trample on userland \Tokenizer. There is one solution to this, and that is to have a vendor namespace for the PHP project itself, naturally the one that is reserved, \PHP. There's a very good reason modern language frameworks claim a couple of root level namespaces, e.g. .NET it's System.* and Microsoft.*, for Java it's java.* -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 17/07/2020 09:23, Lester Caine wrote: So does that also apply to \Ext? Currently the selection of extensions is flexible and most distributions allow the easy repackaging of just what is available. Creating a 'core' set off extensions under \PHP is essentially saying 'you will make these available' while \Ext is a second class citizen? Personally I think every package even if relegated to PECL deserves to be under \PHP or alternately ONLY the essential core engine components go under \PHP and everything else is \Ext Things under \PHP will be related to either the engine itself, universal helpers, or PHP as a language. Everything else, including almost all extensions bundled with php-src, would go under \Ext Many of the 'exotic' functions such as 'reflection' are not essential for writing good code, so a core \PHP which defines an essential working set of functions does make sense. What HAS been lost is the development of better extensions such as a \Ext\String or \Ext|Array extension that is more 'object orientated' while leaving the legacy functions wrapped in \PHP ... Object-orientated styles for strings / arrays provided by the engine would still go in the root. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 17/07/2020 04:49, Levi Morrison via internals wrote: I don't care to debate it. I will just vote no. Fair enough, however the point of the internals mailing list and discussion period is to debate the RFCs :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 17/07/2020 02:58, Levi Morrison via internals wrote: 2. I don't think this is solving any problems, really: - Code can move from PHP land to an extension and back again. Should the namespace change just because it moved one way or the other? I vote no. This is not what the RFC proposes. The point of \Ext is that there would be no need to rename them when moving in or out of core. I'm strongly in the "make namespace short and flat" camp. Deeply nested namespaces make more sense when you need to distinguish between projects within a company, for a contrived example `Amazon\WebServices\SDK`. I can see there being multiple projects with Amazon, and I can see there being multiple WebServices projects. Removing a namespace segment doesn't make a lot of sense either, except for perhaps collapsing the first two to `AWS` but this is just another point to my short and flat camp. This deeply nested company organization is not the territory we are in as a project, so we should keep it simple and keep our namespace short and simple. How flat would you want it to be? This RFC proposes 1 level before the name of the feature, either PHP or Ext depending on its location. The purpose of that one level is to avoid extensions trampling into multiple userspace naming areas. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings
On 16/07/2020 15:43, Nikita Popov wrote I haven't backported any deprecation warnings to 7.4. Adding deprecations to released versions is a hard no-go. My apologies. I'd got my wires crossed with seeing https://github.com/php/php-src/pull/3917 appear on the PRs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings
On 16/07/2020 16:15, G. P. B. wrote: I do agree that accepting trailing whitespace may be considered suboptimal but as leading whitespaces don't even emit an E_NOTICE it is impossible to drop this "feature". Didn't someone (Nikita?) already back-port a warning to 7.4 about some changes coming in 8.0? So it's not really impossible... it just takes the will to do it. We can keep making small tweeks trying to make it better, or we can just do the "proper" thing, reject everything except exclusively properly-formatted numbers, and put the issue to bed permanently. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
