Re: [PHP-DEV] Moving a tmpfile()?
> Why move the temporary file when it is already a temporary file, right? If you don't want to have to write the file again with a copy? On Sat, May 6, 2023 at 1:56 PM Hans Krentel wrote: > > > > On Saturday 29 April 2023 09:32:42 (+02:00), Dan Liebner wrote: > > > Are there any inherent problems with moving a file created with > tmpfile()? > > > > In practice, it seems that it can be done and the file will not be > deleted > > after being moved and the file handle closed. > > yes, not that it would be inherently wrong to do it that way, it is that > tmpfile() already offers the file handle, so you can rewind() and put the > contents in your destination file: > > > $destinationPath = tempnam(__DIR__, '.destination.'); > $tempHandle = tmpfile(); > > # ... operate on $tempHandle ... > fwrite($tempHandle, "hello world\n"); > > rewind($tempHandle); > $result = file_put_contents($destinationPath, $tempHandle); > fclose($tempHandle); > > > Why move the temporary file when it is already a temporary file, right? > > -- hakre >
[PHP-DEV] Moving a tmpfile()?
Are there any inherent problems with moving a file created with tmpfile()? In practice, it seems that it can be done and the file will not be deleted after being moved and the file handle closed. Thanks, Dan
Re: [PHP-DEV] Future stability of PHP?
>
> The change in null handling. We have a codebase that dates to 1998. It's
> fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that
> took almost a year due to the change in null handling. We have 40 XML and
> JSON APIs with various banks. Elements may or may not exist. The database,
> which is 45TB, has nulls all over it. And when it was all "upgraded" to run
> on PHP8 all we really got that was useful to us is two new string
> functions. And a codebase that now has ?? as every third line.
This is probably my biggest stylistic gripe with PHP 8+ just because of how
ubiquitous the "undefined array index" scenario is.
In JavaScript:
```
let obj = {};
obj['undefinedkey'] === undefined;
let str = `Welcome, ${obj['undefinedkey'] ?? 'Customer'}!`;
if( obj['undefinedkey'] || $obj['undefinedkey2'] ) doSomething();
```
In PHP:
```
$obj = [];
($obj['undefinedkey'] ?? null) === null;
$str = "Welcome, " . ($obj['undefinedkey'] ?? 'Customer') . "!";
if( ( $obj['undefinedkey'] ?? null) || ($obj['undefinedkey2'] ?? null) )
doSomething();
```
On Mon, Apr 10, 2023 at 8:35 AM Jeffrey Dafoe wrote:
>
> > I wonder about this every time I hear this claim. What exactly changed
> in PHP
> > 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be
> a
> > little more difficult because of some of the recent deprecations, but
> that's
> > still years ahead of us. So what's exactly driving people away from PHP
> 8?
> > Why is the adoption dwindling?
>
> The change in null handling. We have a codebase that dates to 1998. It's
> fairly well written. Upgrading to 8 was a major effort (4 devs, 2 QA) that
> took almost a year due to the change in null handling. We have 40 XML and
> JSON APIs with various banks. Elements may or may not exist. The database,
> which is 45TB, has nulls all over it. And when it was all "upgraded" to run
> on PHP8 all we really got that was useful to us is two new string
> functions. And a codebase that now has ?? as every third line.
>
> -Jeff
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Future stability of PHP?
I agree with the OP's sentiment here. If I was starting a codebase from scratch today, I'd probably go with Node. I find that writing modern JavaScript is way easier than writing PHP these days, and the breaking changes in newer PHP versions make writing code harder rather than easier. PHP is the foundation for many legacy codebases, and breaking old projects isn't really a great selling point of new PHP versions. Hopefully this scenario will affect enough people that 7.4 will continue to be maintained by some group of people into the foreseeable future. Best, Dan On Sat, Apr 8, 2023 at 4:28 PM Kamil Tekiela wrote: > Hi Stephan, > > Generally, PHP tries to keep as much backwards compatibility as possible. > Breaking changes are limited to minimum and done in the least obstructive > way possible. When a deprecation is introduced, you have at least 3 years > to update your code. > But PHP also tries to move forward and the language improves each year. We > certainly got many more features than breaking changes. Just think of match > expression, enums, attributes, constructor property promotion, new Random > API, readonly properties/classes, first-class callable, consistent errors > and many more. > The biggest improvement in PHP 7 and 8 was a comprehensive type system. > It's something that you don't have to use, therefore doesn't affect > existing code much, but makes development so much more enjoyable and less > bug-prone. I know I have discovered many bugs because of migration to PHP 8 > and introduction of proper types. > And this is the direction PHP is going in. The language is still dynamic > and allows for taking the easy route, but new features focus on reducing > bugs by making the code's behaviour less surprising. > > If you try to adhere to clean code principles, upgrades should not be a > huge problem. Use static analysis and good tests. Learn and follow clean > code practices, e.g. SOLID. Use abstraction in your code; it's better to > change code only in one place than change it across hundreds of files. Some > tools help you during migrations, such as Rector and phpcbf, but to use > them proficiently, your code needs to be free from surprises. Dynamic > properties are a very good example of surprising behaviour. By looking at > the definition of the class, you don't know what properties it has. If any > of the methods use undefined properties, both you and static analysers will > be surprised by this. > > There are certain things you should avoid in your code like fire. Not > because they might be removed from the language, but because they make your > code unclean and cause bugs. Here is my list: > - Arrays. Yes, they are a major feature of the language but also a major > pain in the... Use proper data structures, which may use arrays internally, > but don't use bare arrays in your code. Value objects and DTOs are > invaluable. > - Isset and empty. They are sometimes necessary and sometimes they are the > easiest choice, but they hide so many bugs. Every time you use any of them, > it should raise an immediate red flag. > - References. I don't understand why the language still has this feature. > Hack got rid of it and that was a very smart decision. You don't need > references. Use them almost never. > - Globals and superglobals. This should not need explaining. Pretty much in > every language, these are pure evil. They make changes to the code an > experience similar to disarming a bomb. It's tempting to use $_GET, $_POST, > $_REQUEST anywhere in your code, but if you want to avoid bugs and > surprises, you'd better stay away from it. There should probably be at most > one place in every project where these are used. > - extract() and compact(), and variable variables. These should only be > used in a very tightly controlled scope, and even then, their usage can be > contested. Ideally, variable variables should not exist in the language; we > have arrays after all. > - Sanitizing filters. Sanitization is too ambiguous term to be useful. What > you should be using is validation and formatting. Validate your inputs to > make sure they are the type/value you expect. Format the output so that it > can't break the context it is in. > - Loose comparison. I have liked that about PHP in the past, but in recent > years I became a strong supporter of strict comparison. Why? Because "0" == > false. Forbid using loose comparison in your coding standard and forget > that it exists. Don't let the language make a fool out of you. You are the > developer and you know what type you expect. > > Following these guidelines will not only help you avoid bugs in your code > but also will make the upgrade process much less cumbersome. This and > adhering to the strictest level of the static analysis tool of your choice > is the recipe for success. > > Try to stay up to date with the changes. Every year when PHP releases a new > version, go over the changelog and make an effort to learn and use new >
Re: [PHP-DEV] PHP code refactoring (was: include cleanup)
Which commit? On Tue, Feb 28, 2023, 3:17 PM Dmitry Stogov wrote: > Hi @internals, > > I have to say that we came to a serious conflict. > > Recently we voted for inluce cleanup RFC > https://wiki.php.net/rfc/include_cleanup and it was declined. > Despite that a series of code refactoring commits from Max were silently > merged into the master. > As this is a violation of the community rules and we should do something. > In my opinion, this should be reverted (I would even think about rebasing > to not pollute the git history). > > Personally, I don't like this refactoring, because it is mainly about > coding preferences and habits. > Anyway, I see that some people like this. Maybe this may attract new > developers. > > OK. Let's do this, but do this in a managed way. The massive uncontrolled > changes is the main problem in the current situation. > Let's define the goal(s), rules, make a plan, summarize this in a new RFC, > accept it. > Then most of the work should be done in a separate branch and merged into > the master all together after a final review. > I (and other authority contributors) wouldn't be able to object against the > terms accepted in RFC. > So a good RFC should be a half of success... > It would be great if PHP Foundation could assign some experienced > developer(s) to be part of this work. > > Thanks. Dmitry. >
Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
> Can you expand a bit on how you think distinguishing "undefined" from
"null" would help?
First off, I would be perfectly happy if undefined array/object index
accesses went back to raising E_NOTICE. Undefined variables already resolve
to NULL so in that sense NULL is already the "undefined" primitive.
That said, if PHP were to introduce an `undefined` primitive, here's what I
think would change:
- NULL remains, and as such represents an "empty", yet defined, value.
- Undefined variables and array/object accesses now resolve to "undefined"
- `$var = undefined` is the equivalent of calling unset($var)
- Biggest breaking change would probably be `$undefinedVar === null` is no
longer true
prop; // undefined, no error
$undy->method(); // fatal error
function($param = undefined) {} // fatal error
// more difficult scenarios...
// JavaScript would throw an error
// classic PHP behavior would resolve to null, therefore now undefined
// either is arguably valid, latter would create need for optional chaining
$undy['key']; // ?
$undy->prop; // ?
Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
Can I also just point out that by current definitions the "null coalescing operator" isn't properly named, it should be the "undefined/null coalescing operator". The only reason it is able to get away with not raising an error for undefined variables is that it's described as "syntactic sugar" for isset(), which is itself the exception to the rule for not raising undefined errors. Other languages, such as JavaScript, would raise an error for an expression such as `undefinedvar ?? 0`. And JavaScript conveniently offers the undefined primitive for precisely handling attempted accesses of undefined keys, while retaining the brevity and convenience of a truthy/falsy `obj.key` check. If you're set on raising errors and eventually exceptions for undefined key accesses, we need a concise, performant way to say `isset($varExpression) ? $varExpression : null` that's still way more concise than `$varExpression ?? null` that's baked into the language. On Tue, Dec 13, 2022 at 7:53 AM Dan Liebner wrote: > > No, code doesn't break. It now shows a warning instead of an error. > There is no behavioural change. > It breaks my app. Does that count? And didn't you follow up by referencing > this as "adding settings that change behaviour"? Does it change behavior or > not? > > > Adding a configuration setting to make this a notice on some > installations and not on others, would just mean that anything that needs > to be able to run everywhere needs to take care to not rely on the setting > either way, making it harder to develop portable code. > What code now relies on this raising a warning rather than a notice that > can't consistently deal with it by using isset or the null coalescing > operator? Or are you subtly referring to the fact that this RFC is a > stepping stone to escalating the severity to throwing an error? > https://wiki.php.net/rfc/undefined_variable_error_promotion -> "This RFC > proposes that accessing an undefined variable is rendered illegal behaviour > in the next major version of PHP, and will result in an Error exception > being thrown if it occurs." > > Here's another suggestion: > Make accesses to undefined array keys (objects, variables, etc) return a > new `undefined` primitive. That way, developers who are focused on writing > concise, readable code can continue to write and maintain code manageably, > and developers who are keen on writing a lot of code in a more "strict" > manner can handle undefined array key accesses consistently, without having > to rely on configuration settings. > > > just fix your code. > Practically speaking, I'd much more likely stay on 7.4 or migrate to Node. > > > On Mon, Dec 12, 2022 at 5:52 PM Derick Rethans wrote: > >> On 12 December 2022 22:20:27 GMT, Dan Liebner wrote: >> >> >It has been proposed to make the error level of "Undefined index" >> >configurable so that teams and individual developers can decide for >> >themselves how they want this situation to be handled. Given that: >> > >> > - PHP has been treating this as an E_NOTICE for over 20 years >> >> But not in the last three years. >> >> > - the change is a breaking change affecting many large codebases >> > ubiquitously (unless one were to unadvisedly suppress E_WARNING >> errors) >> >> No, code doesn't break. It now shows a warning instead of an error. There >> is no behavioural change. >> >> > - 7.4 is now deprecated >> >> Yes, as each release does 2+1 years. Which also means you've had 3 years >> to address this in your code base(s) already. >> >> >I think making the error level of "Undefined index" configurable is a >> very >> >reasonable suggestion, and I support it. >> >> Adding a configuration setting to make this a notice on some >> installations and not on others, would just mean that anything that needs >> to be able to run everywhere needs to take care to not rely on the setting >> either way, making it harder to develop portable code. >> >> We're also not generally anything near keen on adding settings that >> change behaviour , and suggesting to add one to make a warning a notice >> seems very far short of a bar that needs to be reached before many of us >> would agree to add a setting to make PHP less portable. >> >> Alternatively you can just fix your code. >> >> >Are we able to revisit this topic as a community and potentially bring in >> >more PHP developers from around the world to weigh in? >> >> You're always free to follow the RFC process, but I think you'll just up >> wasting your, and everybody else's, time with it. >> >> I can't see this being reversed, nor a setting added for, through an RFC >> process. >> >> cheers >> Derick >> >>
Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
> No, code doesn't break. It now shows a warning instead of an error. There is no behavioural change. It breaks my app. Does that count? And didn't you follow up by referencing this as "adding settings that change behaviour"? Does it change behavior or not? > Adding a configuration setting to make this a notice on some installations and not on others, would just mean that anything that needs to be able to run everywhere needs to take care to not rely on the setting either way, making it harder to develop portable code. What code now relies on this raising a warning rather than a notice that can't consistently deal with it by using isset or the null coalescing operator? Or are you subtly referring to the fact that this RFC is a stepping stone to escalating the severity to throwing an error? https://wiki.php.net/rfc/undefined_variable_error_promotion -> "This RFC proposes that accessing an undefined variable is rendered illegal behaviour in the next major version of PHP, and will result in an Error exception being thrown if it occurs." Here's another suggestion: Make accesses to undefined array keys (objects, variables, etc) return a new `undefined` primitive. That way, developers who are focused on writing concise, readable code can continue to write and maintain code manageably, and developers who are keen on writing a lot of code in a more "strict" manner can handle undefined array key accesses consistently, without having to rely on configuration settings. > just fix your code. Practically speaking, I'd much more likely stay on 7.4 or migrate to Node. On Mon, Dec 12, 2022 at 5:52 PM Derick Rethans wrote: > On 12 December 2022 22:20:27 GMT, Dan Liebner wrote: > > >It has been proposed to make the error level of "Undefined index" > >configurable so that teams and individual developers can decide for > >themselves how they want this situation to be handled. Given that: > > > > - PHP has been treating this as an E_NOTICE for over 20 years > > But not in the last three years. > > > - the change is a breaking change affecting many large codebases > > ubiquitously (unless one were to unadvisedly suppress E_WARNING errors) > > No, code doesn't break. It now shows a warning instead of an error. There > is no behavioural change. > > > - 7.4 is now deprecated > > Yes, as each release does 2+1 years. Which also means you've had 3 years > to address this in your code base(s) already. > > >I think making the error level of "Undefined index" configurable is a very > >reasonable suggestion, and I support it. > > Adding a configuration setting to make this a notice on some installations > and not on others, would just mean that anything that needs to be able to > run everywhere needs to take care to not rely on the setting either way, > making it harder to develop portable code. > > We're also not generally anything near keen on adding settings that change > behaviour , and suggesting to add one to make a warning a notice seems very > far short of a bar that needs to be reached before many of us would agree > to add a setting to make PHP less portable. > > Alternatively you can just fix your code. > > >Are we able to revisit this topic as a community and potentially bring in > >more PHP developers from around the world to weigh in? > > You're always free to follow the RFC process, but I think you'll just up > wasting your, and everybody else's, time with it. > > I can't see this being reversed, nor a setting added for, through an RFC > process. > > cheers > Derick > >
[PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
First off, hello everyone, I'm Dan. I love PHP and I've been a PHP developer for over 20 years. The recent change to elevating "Undefined index" from E_NOTICE to E_WARNING set forth and passed by https://wiki.php.net/rfc/engine_warnings to me seems antithetical to what PHP has been and what has made it a choice for developers over the last few decades. As the RFC points out, "Some languages, such as JavaScript, do not consider accesses to undefined array keys to be an error condition at all, and allow such an operation to be performed silently." For the last 20 years, it's been my impression that PHP also embraced this philosophy, and that raising an E_NOTICE for "Undefined index" was more or less offered as a debugging tool, as a matter of practicality. JavaScript returns the undefined primitive for accesses to undefined array and object keys. PHP returns the NULL primitive respectively despite raising an error. Here's my biggest criticism: the change essentially forces this: $arr['key'] to be rewritten as this (or some other intolerably bad alternative): isset($arr) && isset($arr['key']) && $arr['key'] This is a major regression in my opinion as far as productivity and readability are concerned. It has been proposed to make the error level of "Undefined index" configurable so that teams and individual developers can decide for themselves how they want this situation to be handled. Given that: - PHP has been treating this as an E_NOTICE for over 20 years - the change is a breaking change affecting many large codebases ubiquitously (unless one were to unadvisedly suppress E_WARNING errors) - 7.4 is now deprecated I think making the error level of "Undefined index" configurable is a very reasonable suggestion, and I support it. Are we able to revisit this topic as a community and potentially bring in more PHP developers from around the world to weigh in? Thank you, Dan
