231: Super Villains

Links from the show:

This episode of PHPUgly was sponsored by:

Cloudways, a managed cloud hosting platform built for your PHP projects.
If you simply wish to focus on your business, Cloudways is the way to go. They take over server management and security and free up time that you can dedicate to growing your business and acquiring new clients.
The Platforms offers a choice of IaaS partners (AWS, Google Cloud, Digitalocean, Linode, and Vultr). In addition, you get a performance-optimized stack, managed backups, and staging environment where you can test your code before pushing it to live servers.
Best of all, Composer and Git come pre-installed so you can get your projects up and running quickly.
All this power, simplicity, and peace of mind falls right with their brand slogan - Moving Dreams Forward
Be sure to visit cloudways.com/en/php-hosting.php today. Sign up using the Promo code PHPUgly and get a $25 credit.

PHPUgly streams the recording of this podcast live. Typically every Thursday night around 9 PM PT. Come and join us, and subscribe to our Youtube Channel, Twitch, or Periscope. Also, be sure to check out our Patreon Page.

Twitter Account https://twitter.com/phpugly

Host:

Streams:

Powered by Restream

Patreon Page

PHPUgly Anthem by Harry Mack / Harry Mack Youtube Channel


Serverless LAMP, Refactoring Legacy Code, and Functional Programming

Eric, John, and Oscar talk about the features and columns from the March 2021 issue, Lambda PHP

Topics Covered

  • Working the Serverless computing and PHP, and the costs potentially involved.
  • Practical applications of functional programming and misconceptions around it versus object-oriented programming (OOP).
  • John and Eric’s attempts at the puzzle for the month about generating hashtags.
  • Using Laravel Sail to manage Docker containers for development and production usage.
  • Salts, Peppers, Hashes, and Passwords
  • Preparing for when your job, industry, or world suddenly shift.
  • Chatting with @mwop about Laminas, Zend Framework, and its future.
  • APIs and the history of using them in web applications. Touching on REST, XML, JSON, and GraphQL.
  • When to use shared hosting for budget-conscious clients.

The post Serverless LAMP, Refactoring Legacy Code, and Functional Programming appeared first on php[architect].


Integrating phone systems, rapidly building apps with Tailwind UI, and dynamically updating Blade components

In this episode, Jake and Michael discuss integrating with hosted phone systems, quickly scaffolding out applications with Tailwind UI, and dynamically updating Blade components with AlpineJS.

This episode is sponsored by Workvivo - the employee communication platform to excite, engage and connect your entire company - and was streamed live.

230:PHP’ing in a Bottle

Links from the show:

This episode of PHPUgly was sponsored by:

Cloudways, a managed cloud hosting platform built for your PHP projects.
If you simply wish to focus on your business, Cloudways is the way to go. They take over server management and security and free up time that you can dedicate to growing your business and acquiring new clients.
The Platforms offers a choice of IaaS partners (AWS, Google Cloud, Digitalocean, Linode, and Vultr). In addition, you get a performance-optimized stack, managed backups, and staging environment where you can test your code before pushing it to live servers.
Best of all, Composer and Git come pre-installed so you can get your projects up and running quickly.
All this power, simplicity, and peace of mind falls right with their brand slogan - Moving Dreams Forward
Be sure to visit cloudways.com/en/php-hosting.php today. Sign up using the Promo code PHPUgly and get a $25 credit.

PHPUgly streams the recording of this podcast live. Typically every Thursday night around 9 PM PT. Come and join us, and subscribe to our Youtube Channel, Twitch, or Periscope. Also, be sure to check out our Patreon Page.

Twitter Account https://twitter.com/phpugly

Host:

Streams:

Powered by Restream

Patreon Page

PHPUgly Anthem by Harry Mack / Harry Mack Youtube Channel


About PHP’s Compromised Git Commit

PHP internals contributor Sara Golemon answers questions from a panel of php[architect] and PHP Ugly contributors about the recent git compromise that affected the PHP project and what they’re doing about it. You can also watch a video of the roundtable with Sara.

More on This

The post About PHP’s Compromised Git Commit appeared first on php[architect].


Special PHP Discussion Panel

This PHP Panel in the spirit of community, openness, and transparency. 

Resources:  

Announcement on PHP Blog - https://www.php.net/archive/2021.php#2021-03-30-1

 Internal Mailing List discussion - https://news-web.php.net/php.internals/113838 

Official Twitter Account of PHP.net - https://twitter.com/official_php 

Participants on the Panel:


PHP Internals News: Episode 80: Static Variables in Inherited Methods

PHP Internals News: Episode 80: Static Variables in Inherited Methods

In this episode of "PHP Internals News" I chat with Nikita Popov (Twitter, GitHub, Website) about the "Static Variables in Inherited Methods" RFC.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:14

Hi I'm Derick, welcome to PHP internals news, the podcast dedicated to explain the latest developments in the PHP language. This is episode 80. In this episode I speak with Nikita Popov again about another RFC that he's proposing. Nikita, how are you doing today?

Nikita Popov 0:30

I'm still doing fine.

Derick Rethans 0:33

Well, that is glad to hear. So the reason why you saying, I'm still doing fine, is of course because we basically recording two podcast episodes just behind each other.

Nikita Popov 0:41

That's true.

Derick Rethans 0:42

If you'd be doing fine 30 minutes ago and bad now, something bad must have happened and that is of course no fun. In any case, shall we take the second RFC then, which is titled static variables in inherited methods. Can you explain what is RFC is meant to improve?

Nikita Popov 1:00

I'm not sure what this meant to improve, it's more like trying to fix a bug, I will say. This is a really, like, technical RFC for an edge case of an edge case, so I should say first, when I'm saying static variables, I'm not talking about static properties, which is what most people use, but static variables inside functions. What static variables do unlike normal variables, is that they persist across function calls. For example, you can have a counter static $i equals zero, and then increment it, and then each time we call the function, it gets incremented each time and the value from the previous call is retained. So that's just the context of what we're talking about.

Derick Rethans 1:43

Why would people make use of static variables?

Nikita Popov 1:46

I think one of the most common use cases is memoization.

Derick Rethans 1:50

Can you explain what that is?

Nikita Popov 1:51

If you have a function that that computes some kind of expensive result, but which is always the same, then you can compute it only once and store it inside the static variable, and then return it. Maybe possibly keyed by by the function arguments, but that's the general idea. And this also works if it's a free standing function. So if it's not in the method where you could store state inside the static property or similar, but also works inside a non method function.

Derick Rethans 2:22

The keyword here in his RFC's title is inherited methods, I suppose. What happens currently there?

Nikita Popov 2:29

There are a couple of issues in that area. The key part is first: How do static variables interact with methods at all? And the second part is how it interacts with inheritance. So first if you have an instance method, with a static variable, then some people expect that actually each object instance gets a separate static variable. This is not the case. The static variables are really bound to functions or methods, they do not depend on the object instance. Second problem is: What happens with inheritance? So you have a parent class with a method using static variables and then you have a child class that inherits this method. There are two ways you can interpret this, either this is still the same method, so it should use the same variables, or you could say okay the inherited method is actually a distinct method and should use separate variables. PHP currently follows the second interpretation.

Derick Rethans 3:24

And is this even the case, if it's overridden, or just when it's inherited? Because there's a difference there supposed as well.

Nikita Popov 3:30

Yeah, this is the basic model that PHP tries to follow but there are quite a few edge cases. The one that's what you mentioned if you override the method, then of course, you're calling the overridden method so the static variables don't even come in. But if you then call the parent method, then usually you would expect, if you do an override and just call the parent that the behaviour is exactly the same as if you didn't override it at all. That's not the case here, because now you're calling the parent method. So the problem you have here is that if you didn't override the method, then the child method and the parent method would have different static variables. Now if you call parent, then you're just calling the parent method, so you get back to one set of static variables, which are the same for both methods. You can see they're the same for both methods, but rather because you're calling the parent method, there is only one method involved, only one set of static variables involved. You can't really just like seamlessly extend a method that uses static variables, without changing the behaviour by accident.

Derick Rethans 4:37

This sounds all very complicated.

Nikita Popov 4:39

Yes I said, I did warn you that this is an edge case of an edge case.

Derick Rethans 4:44

But I think the whole idea behind the RFC is to make it less complicated.

Nikita Popov 4:48

Yes, this is like not the, the only issue you can run into. There is another one that we have actually addressed separately, but which still exists on earlier PHP versions, which is that the value of the static variables depend on the time of inheritance. Let me be a bit more explicit there. What we had in previous versions is that half your parent method was a static variables, then you call that parent method, static variables change, then you inherit it. And again, call the inherited method. In that order: first declare the parents, call it, declare the child, call it. In that case we will actually take the static variables at the time, where the inheritance actually happens. The first call onto the parent method modify the static variables, then we will use some modified variables. From that point on, it will have a separate copy, the child method, but it will like pick up these original modifications before inheritance happens. Now in PHP 8.1, we actually already fixed that so that we always use the original values, but this is like just one more thing to the list of weird things that happen, if you use static variables inside methods and you inherit them.

Derick Rethans 6:06

I think I understand more of it now.

Nikita Popov 6:08

I think you understand more than you ever wanted to know.

Derick Rethans 6:12

You've mentioned the edge cases. What is the result, going to be once this RFC passes, which I'm going to think is quite likely

Nikita Popov 6:21

The result is, hopefully, simpler than what we have, namely that static variables are really bound to a specific function or method declaration. If you have one method using static variables, then you have only one set of static variables ever. If it's inherited, you still reuse the same static variables because there is no separate inherited method. It's just the same method in the child class. That's the concept.

Derick Rethans 6:52

And if you override it in an inherited class?

Nikita Popov 6:55

If you override it, and you call the parent method, then the behaviour is unchanged because you still have just a single set of static variables, so there is no edge case here any more because the child, the child method never had a separate set.

Derick Rethans 7:10

But if the overridden method also defines its own static variable with the same name?

Nikita Popov 7:17

That's possible. In that case, once again this rule is that each method has its own static variables and methods can have static variables and the child method can have them as well, if they are overridden and there are no name clashes between them.

Derick Rethans 7:32

Because they are going to be totally separated, meaning that any code you run in the inherited methods will only affect its static variables, and any code that runs in the original methods only affects the static variables that are bound to that specific method.

Nikita Popov 7:50

Exactly. I mean, in the end, static variables are really the type of global state, just a type that is kind of isolated to a specific namespace and doesn't cause clashes, so in that sense, it's important that these things are isolated.

Derick Rethans 8:06

And that would also make the behaviour, a lot more easier to explain than it currently is. Because every methods, has its own set of static variables.

Nikita Popov 8:15

Yes.

Derick Rethans 8:15

Or I should say, every declared methods, has its own set of static variables.

Nikita Popov 8:20

I guess that is an important distinction. If you can see the methods inside your code and see the static variable inside it, then that is a distinct one. If we ignore the exception of traits.

Derick Rethans 8:34

You're going to have to explain that as well.

Nikita Popov 8:37

Well traits are always a special snowflake. Our general model for traits is that they are compiler assisted copy and paste. So a trait should roughly behave as if you just copied all the methods into the class that's using the trait. And in that sense, if you are actually copying the code of your method with a static variables, then it should also use a distinct set of static variables for each use. And that is also how it is proposed to behave. So that is like the one exception where you have a single method declaration in your code, but each using class will get a separate set of static variables.

Derick Rethans 9:15

Because the code is copied in place, instead of linked, or used in place. It's also the case for all the methods declared in traits, they're also copied into the same symbol table as the methods belong to a class.

Nikita Popov 9:32

Yeah, that's right.

Derick Rethans 9:33

Should be reference counted in some way because you probably won't duplicate the exact data.

Nikita Popov 9:38

We of course don't actually copy the methods, or at least most of the methods, but from the programmer perspective that's how it works

Derick Rethans 9:46

Why do you say most of the methods, and not all the methods?

Nikita Popov 9:50

We separate two things there. There is the method itself. So the op-array, and then there is all the stuff it uses like the opcodes the like arguments information and so on. What they do for traits, is we share all the data, and only create a separate op-array. Reason is that there are some differences. For example, we have to adjust the scope, we have to adjust possibly the function name if aliases are involved, and we have to adjust the static variables. So it's like kind of a partial copy we do.

Derick Rethans 10:22

Which is probably the most efficient way of doing it?

Nikita Popov 10:24

Yes.

Derick Rethans 10:25

Because this RFC is changing behaviour due to bug fixes, I would probably argue, what kind of backwards compatibility issues are there? And have you looked at how much code that actually impacts?

Nikita Popov 10:39

I haven't looked how much code it impacts because this seems like pretty hard to really analyse. I mean I guess something we could easily check is how much static variables are used in methods at all. But it would be hard to distinguish whether this change. I mean how to distinguish in a completely automated way. Whether this change makes behavioural difference for a particular use case or not. So I can't really give information on that, though I would expect that impact is relatively low because the common use cases, things like memoization, they aren't affected by it, or they are only affected by it in the sense that: Then you will memoize a value only once for the whole class hierarchy instead of memoizing it once for each like inherited class.

Derick Rethans 11:32

So, it's going to improve the situation there as well, is pretty much what you're saying?

Nikita Popov 11:36

Yeah, but I'm sure there are also cases where the previous behaviour was like intentionally used. I mean it was never documented, but you know if some behaviour exists, people will always make use of it in the end, but I can't really say exactly how much impact this would have.

Derick Rethans 11:55

Do you have anything else to add, discussing this RFC?

Nikita Popov 11:59

No, I think that's it.

Derick Rethans 12:00

Then I would like to thank you for taking the time today, again, to talk to me about static variables in inherited methods.

Nikita Popov 12:08

Thanks for having me once again.

Derick Rethans 12:16

Thank you for listening to this instalment of PHP internals news, a podcast dedicated to demystifying the development of the PHP language. I maintain a Patreon account for supporters of this podcast as well as the Xdebug debugging tool. You can sign up for Patreon at https://drck.me/patreon. If you have comments or suggestions, feel free to email them to derick@phpinternals.news. Thank you for listening and I'll see you next time.


Interview with Juciellen Cabrera

Eric and John get a chance to sit down and interview Juciellen Cabrera, on her article Refactoring—Does This Code Spark Joy? in the March 2021 issue.

Topics Covered

  • The joy of revisiting legacy code.
  • How she started as a programmer via an internship.
  • Moving from Brazil to Ireland via a local conference opportunity.
  • Her involvement with php[women] in Brazil.
  • Working with back-end APIs.
  • The direction of PHP as a programming language.

The post Interview with Juciellen Cabrera appeared first on php[architect].


229: No Perceived Value

Links from the show:

This episode of PHPUgly was sponsored by:

PHPUgly streams the recording of this podcast live. Typically every Thursday night around 9 PM PT. Come and join us, and subscribe to our Youtube Channel, Twitch, or Periscope. Also, be sure to check out our Patreon Page.

Twitter Account https://twitter.com/phpugly

Host:

Streams:

Powered by Restream

Patreon Page

PHPUgly Anthem by Harry Mack / Harry Mack Youtube Channel


PHP Internals News: Episode 79: New in Initialisers

PHP Internals News: Episode 79: New in Initialisers

In this episode of "PHP Internals News" I chat with Nikita Popov (Twitter, GitHub, Website) about the "New in Initialisers" RFC.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:14

Hi, I'm Derick. Welcome to PHP internals news, a podcast dedicated to explain the latest developments in the PHP language. As you might have noticed, the podcasts are currently not coming out once every week, as there are not enough RFCs being submitted for weekly episodes. I suspect that this will change soon again. This is episode 79. In this episode, I speak with Nikita Popov, about a few more language additions that he's proposing. Nikita, how are you doing today?

Nikita Popov 0:43

I'm doing well, Derick, how are you doing?

Derick Rethans 0:45

I'm pretty good as though, I always much happier when it's sunny outside.

Nikita Popov 0:48

Yeah, for us to weather also turned today. Yesterday it was still cold.

Derick Rethans 0:53

We're here to talk about a few RFCs. The first one, titled "New in Initializers". What is this RFC about?

Nikita Popov 1:00

The context is that PHP has basically two types of expressions: ones, the ones used on normal code, and the other one in a couple of special places. These special places include parameter default values, property default values, constants, static variable defaults, and finally attribute arguments. These don't accept arbitrary expressions but only a certain subset. So we call those usually constant expressions, even though they are not maybe constant in the most technical sense. The differences really that these are evaluated separately so they don't run on the normal PHP virtual machine. There is a separate evaluator that basically evaluates an abstract syntax tree directly. They are just like, have different technical underpinnings.

Derick Rethans 1:49

Because it is possible to for example, define a default value to seven plus 12?

Nikita Popov 1:54

Exactly. It's possible to define it to seven plus 12, but maybe not to seven plus variable A, or seven plus some function call or something like that.

Derick Rethans 2:03

I guess the RFC is about changing this so that you can do things like this. What are you proposing to add?

Nikita Popov 2:09

Yes, exactly. So my addition is a very small one, actually. I'm only allowing a single new thing and that's using new, so you can use new, whatever, as a parameter default, property default, and so on.

Derick Rethans 2:23

In this new call, pretty much a constructor call for a class of course, can arguments to be dynamic, or do they need to be constant as well?

Nikita Popov 2:33

Rules are always recursive, so you can like pass arguments to your constructor, but they also have to follow the usual rules. So again, they also have to be constant expressions, or after this RFC, they can also include new, but they cannot include variable references and so on.

Derick Rethans 2:50

Is this something that is being defined at the grammar level or somewhere else?

Nikita Popov 2:55

We actually used to define that at the grammar level back in PHP five, but nowadays we just accept all expressions, and then we print you a bit nicer error message if it turns out it's not supported in this context.

Derick Rethans 3:08

And that happens when the AST is created.

Nikita Popov 3:10

Yeah, exactly.

Derick Rethans 3:11

The new syntax additions is to allow new in default values in places. The RFC talks a little bit about the evaluation order, and what is this and why is is important.

Nikita Popov 3:23

This is really the critical part. Right now, the kinds of things you can use in constant expressions are well as the name says, these can supposed to be constant, and not dynamic. This is not entirely true because, for example, you can like reference a class constant and referencing a class means that you call an autoloader. And that can run arbitrary code. Or you can trigger a notice that triggers an error handler and that also runs arbitrary code, like more like at the design level at the conceptual level, these really are constant expressions that are not supposed to have any side effects. Allowing new changes that in the big way, because new calls constructors and constructors can do whatever they want. I think it would be unusual to print out a string in the constructor, but some people might want to create a database connection there. The question of where exactly these expressions get evaluated becomes more important now, so we have to think about that a bit more carefully. Previously this was never really formally specified, how the evaluation works. There are some cases where it's pretty clear cut, for example, parameter default value of course gets evaluated when you call the function, and that parameter hasn't been passed. Similarly if you define a global constant, then the value is evaluated when you define the constant. And then there are the problematic cases, that I'm actually still not sure what to do about. The problematic cases are class constants, and static properties. Because the way these work right now is that they are evaluated lazily, so when you declare the class, they are not evaluated, and then later if you use the class, at least most uses of the class, they will be evaluated.

Derick Rethans 5:07

It would happened when you're done instantiate the class?

Nikita Popov 5:09

For example, yes. If you instantiate the class, if you add a static property and so on. But for example, not if you extend the class. In cases that like might potentially meet the evaluated initializers. The problem here is that, um, of course, if now your expressions can have side effects, then it's not great if you don't have like hard guarantee when it's actually going to be evaluated. On the other hand, what I actually implemented already, but I'm not sure it's a good idea is to change it to evaluate the expressions equally, so when you declare the class, we immediately evaluate all the static properties and constants.

Derick Rethans 5:47

I think I found a problem with that as well. For example, if one of the default values is doing new DateTime for example, if you rely on that happening when you instantiate the object, you will get a different time than when you declare a class.

Nikita Popov 6:01

I probably should have mentioned that explicitly. So when it comes to properties we'll always evaluate when you create the object. If you do a new DateTime then you will always get a new DateTime for each object, otherwise it wouldn't really make sense. The problem with the, with evaluation order for the static properties is, that if we evaluate immediately when they declare the class, then we can run into issues with dependencies. If you're using auto loading it's usually not a problem, but if you like declare classes manually, then you might have one class on using a constant from a class that you declare later on. Right now, that works fine, because the initializers are evaluated lazily, but if we evaluate them immediately then this is going to throw a fatal error because it says okay the class hasn't been declared yet. That's a backwards compatibility break, and there are also some other issues, for example with preloading, where it's not really clear when exactly we should be evaluating things in that context. So this is a point I'm undecided on, when things should evaluate. If we should stick with the current lazy evaluation or make it easier or possibly just limit the RFC, to not allow new inside static properties and class constants, because, at least for me personally, those are not the main use case. The three things that seem most important to me are parameter default, property default, I mean non static property default, and usage in attribute arguments.

Derick Rethans 7:29

When I was reading the RFC, I was realizing that if a constructor throws an exception, for example if it's a default argument to a method, then what would happen? Would the method fail, or, or would the method call fail or something else?

Nikita Popov 7:45

It would behave basically the same way as if you initialize the method argument, inside the method, you could do like you would do right now like with a null check maybe. So you would just get an exception thrown inside the method, and it would fail.

Derick Rethans 8:01

And is that the same if you would use it as the new new syntax as a default value to have constructor arguments as well?

Nikita Popov 8:09

Yeah, I think there's a situation would be the same, the one special case is if you use it as a property default, and then the instantiation fails, then we treat this basically the same way as the constructor having failed, which is a special situation, a slightly special situation, because we will also not call the destructor in that case. So we say that the object has been incompletely constructed so it will not get destructed.

Derick Rethans 8:38

And of course if this is a standard class property, then this happens on instantiation of the class. How would this work if it would be for a static property?

Nikita Popov 8:50

For a static property, well that, that depends again on the whole question of evaluation order. So for example the way things work right now, like without this proposal, is for example if you have a static property and you're referencing it constant that doesn't exist. Then, when you try to use the class you get an exception that okay undefined constant whatever. If you try to use it again, you still get the same exception, so you get this exception every time you use a class. This is what would happen on this case as well.

Derick Rethans 9:24

So it wouldn't happen on class declaration, but when you start using it?

Nikita Popov 9:29

Depending on where we evaluate. Either only on use or the first time on declaration and then afterwards in each use. If you still try to use it despite the declaration having failed, which is an odd thing to do but you would have to counter it somehow.

Derick Rethans 9:45

You know, if it is possible to do people will find a way how to do it.

Nikita Popov 9:48

Yes, certainly.

Derick Rethans 9:49

Can you talk a little bit about recursion protection as well because the RFC talks about that?

Nikita Popov 9:54

Well that's another edge case. So if you create an, have an, for example Class A with a property that has an initializer new A. That means when you create an object of class A, and try to initialize it you have to create another object, and then another object, and another, and we have to detect that situation, or we do detect that situation and for nice exception instead of, resulting in a stack overflow.

Derick Rethans 10:20

Which is beneficial.

Nikita Popov 10:21

Yes, because most people do not know what to do when people went PHP throws a segmentation fault, so they do prefer exceptions, usually.

Derick Rethans 10:30

I would too. The RC also talks about, there are some issues around traits which I didn't quite fully understand, would you mind explaining that to me?

Nikita Popov 10:38

The issue here is that traits can have properties and or rules. A rule is that if you have two traits, used in the same class, and declaring the same property, they have to be compatible. And compatible means effectively they have to be exactly the same. So, same visibility and same default value. The trouble here is that if we are dealing with an instance property, which has a new expression as a default value, then we have to somehow check that these are the same. It would be not great if we actually had to evaluate the initializer to do that because, I mean it's okay if it's just you know, with initializer something like one plus two, but if it's an actual new expression we don't want to create objects which again might have side effects and so on. What I'm specifying is that if you have a trait property with this kind of dynamic initializer, so using the new expression, than we will always consider it not compatible.

Derick Rethans 11:36

Would it currently be compatible with one of those trait properties, it says seven plus three, for example?

Nikita Popov 11:42

That will be compatible, which is actually, I think relatively new thing. We used to not evaluate initializers and traits at all, and say those are incompatible and that changed at some point and seven point, I don't know which version. But in this case we would go back to saying it's incompatible, because at least I don't see a good way to make it compatible and I don't think it's particularly important to support that case.

Derick Rethans 12:10

Do you have any information about how much traits are actually used?

Nikita Popov 12:15

Well, I know that Laravel uses them. But I have no idea how much.

Derick Rethans 12:22

One last thing I think RFC mentioned, is that it also has an effect on attributes, that it sort of gets nested attributes in by the back door. How does that work?

Nikita Popov 12:33

I wouldn't call it the back door. Exactly. I have to be honest, I didn't think about attributes at all when writing this proposal, what I had in mind is mainly parameter defaults, and property defaults. But yeah, attribute arguments also use the same mechanism and are under the same limitations. So now you can use new as an attribute argument. And this can be used to effectively nest attributes, so the example I've seen from Symfony is that they have, for example, assertions. They have an assert all attribute which has the which accepts, which wants to accept a list of assertion attributes. And now you can actually do that because you can, um, create these attribute objects recursively. The example from the RFC is assert all, then new assert not null, new assert length max six.

Derick Rethans 13:26

That's actually kind of neat, that is just ends up starting to work on right?

Nikita Popov 13:30

Yeah, I mean, I read the thread for Symfony how they are trying to work around that. They have various ideas of how to do it and it's all pretty ugly. So I think it's nice to have a more or less proper solution for that.

Derick Rethans 13:45

They'll just have to wait until PHP 8.1.

Nikita Popov 13:48

Yes, that is the disadvantage.

Derick Rethans 13:51

Out later this year.

Derick Rethans 13:53

Are there any backwards incompatible changes?

Nikita Popov 13:56

That again comes back to the evaluation order the problem. Originally I had intended to this, this to be compatible. Now if we change evaluation order then it is breaking, depending on that, the answer is yes or no, I am still not sure on that one.

Derick Rethans 14:11

Because I think PHP eight one already has a breaking changes in there where the order of declaration of properties is now different.

Nikita Popov 14:19

Yeah, that the change, though I hope that does not affect people too much because it's mostly about debugging functionality, which of course you are kind of interested in.

Derick Rethans 14:29

Yep, it broke my tests, which is a good thing because it means that my tests cover all the edge cases as well. I think we sort of done discussing this RFC, is there anything else that might ends up being added here in the future, or what still needs to be hammered out before you can put it up to vote?

Nikita Popov 14:47

Apart from the evaluation order question that I have been continuously mentioning, the future scope would be to extend this to not just new expressions, but also for example static method calls, popular alternative pattern is to not use constructors, but named constructors, which are implemented as static methods, and similarly also function calls for example so you can use something like strlen() or count inside an initializer.

Derick Rethans 15:13

Isn't strlen a language construct now?

Nikita Popov 15:15

No it isn't. It has an optimized implementation in the virtual machine, but it's still technically a normal function call.

Derick Rethans 15:23

Because I remember that, breaking tests in Xdebug as well at some point, because it suddenly didn't suddenly was no longer a function call.

Nikita Popov 15:30

Things do tend to break in Xdebug.

Derick Rethans 15:34

Okay, I'm used to it. Thank you, Nikita for taking the time to talk about your new in initializers RFC.

Nikita Popov 15:40

Thanks for having me.

Derick Rethans 15:45

Thank you for listening to this instalment of PHP internals news, a podcast dedicated to demystifying the development of the PHP language. I maintain a Patreon account for supports of this podcast as well as the Xdebug debugging tool. You can sign up for Patreon at https://drck.me/patreon. If you have comments or suggestions, feel free to email them to derick@phpinternals.news. Thank you for listening and I'll see you next time.