81 episodes

This is the 'PHP Internals News' podcast, where we discuss the latest PHP news, implementations, and issues with PHP internals developers and other guests.

PHP Internals News Derick Rethans

    • Technology

This is the 'PHP Internals News' podcast, where we discuss the latest PHP news, implementations, and issues with PHP internals developers and other guests.

    PHP Internals News: Episode 81: noreturn type

    PHP Internals News: Episode 81: noreturn type

    PHP Internals News: Episode 81: noreturn type


    London, UK

    Thursday, April 15th 2021, 09:09 BST



    In this episode of "PHP Internals News" I chat with Matthew Brown (Twitter) and Ondřej Mirtes (Twitter) about the "noreturn type" 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:15

    Hi I'm Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 81. Today I'm talking with Matt Brown, the author of Psalm and Ondřej Mirtes, the author of PHPStan, about an RFC that I propose to alter the noreturn type. Matt, would you please introduce yourself?


    Matthew Brown 0:37

    Hi, I'm Matthew Brown, Matt, I live in New York, I'm from the UK. I work at a company called Vimeo, and I've been working with for the past six years on a static analysis tool called Psalm, which is my primary entry into the PHP world, and I, along with Ondřej authored this noreturn RFC.


    Derick Rethans 1:01

    Alright Ondřej, would you please introduce yourself too?


    Ondřej Mirtes 1:04

    Okay, I'm Ondřej Mirtes, and I'm from the Czech Republic, and I currently live in Prague or on the suburbs of Prague, and I've been developing software in PHP for about 15 years now. I've also been speaking at international conferences for the past five years before the world was still alright. In 2016, I released PHPStan, open source static analyser focused on finding bugs in PHP code basis. And somehow, I found a way to make a living doing that so now I'm full time open source developer, and also father to two little boys.


    Derick Rethans 1:35

    Glad to have you both here. We're talking about something that clearly is going to play together with static analysers. Hence, I found this quite interesting to see to have two competitive projects, or are the competitive, or are the cooperative.


    Matthew Brown 1:56

    I think half and half.


    Derick Rethans 1:57

    Half and half. Okay.


    Ondřej Mirtes 1:59

    Competition is a weird concept in open source where everything is released for free here that


    Derick Rethans 2:04

    That's certainly true, but you said you're making your living out of it now so maybe there was something going on that I'm not aware of. In any case, we should probably chat about the RFC itself. What's the reason why you're wanting to add to the noreturn type?


    Ondřej Mirtes 2:18

    I'm going to start with a little bit of a detour, because in recent PHP development, it has been a trend to add the abilities to express various types natively, in in the language syntax. These types, always originally appeared in PHP docs for documentation reasons, IDE auto completion, and later were also used, and were being related with static analysis tools. This trend of moving PHP doc types tonight this type started probably with PHP seven that added scalar type hint. PHP 7.1 added void, and nullable type hints, 7.2 added object type, 7.4 added typed properties. And finally, PHP, 8.0 added union types. Right now to PHP community, most likely waits for someone to implement the generics and intersection types, which are also widely adopted in PHP docs, but there's also a noreturn, a little bit more subtle c

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

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

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


    London, UK

    Thursday, April 1st 2021, 09:08 BST



    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 me

    PHP Internals News: Episode 79: New in Initialisers

    PHP Internals News: Episode 79: New in Initialisers

    PHP Internals News: Episode 79: New in Initialisers


    London, UK

    Thursday, March 25th 2021, 09:07 GMT



    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

    PHP Internals News: Episode 78: Moving the PHP Documentation to GIT

    PHP Internals News: Episode 78: Moving the PHP Documentation to GIT

    PHP Internals News: Episode 78: Moving the PHP Documentation to GIT


    London, UK

    Thursday, March 11th 2021, 09:06 GMT



    In this episode of "PHP Internals News" I chat with Andreas Heigl (Twitter, GitHub, Mastodon, Website) to follow up with his project to move the PHP Documentation project from SVN to GIT, which has now completed.

    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:15

    Hi, I'm Derick. Welcome to PHP internals news, the podcast dedicated to explaining the latest developments in the PHP language. This is Episode 78. In this episode, I'm talking with Andreas Heigl about moving the PHP documentation to GIT. Andreas, would you please introduce yourself?


    Andreas Heigl 0:35

    Hi yeah I'm Andreas, I'm working in Germany at a company doing PHP software development. I'm doing a lot of stuff in between, as well. And one of the things that I got annoyed, was always having to go through hilarious ways of contributing to the PHP documentation, every time I found an issue with that. So at one point in time, I thought why not move that to Git and, well, here we are.


    Derick Rethans 1:07

    Here we are five years later, right? Because we already spoke about moving the documentation to GIT back in 2019 and Episode 28. But now it has finally happened, so I thought it'd be nice to catch up and see what actually has changed and how we ended up getting here. Where would you want to start. What was the hardest thing to sort out in the end?


    Andreas Heigl 1:27

    Well the hardest thing in the end to sort out was people, as probably always in software development. The technical oddities and the technical bits and pieces were rather fast to solve. What really was taking a long time was, well for one thing, actually, consistently working on that. And on the other hand, chasing down people to actually get stuff done. Because one of the major things here was not the technical side but getting the bits and pieces of information together to get access to the different servers, to the infrastructure of the PHP ecosystem, and chasing down the people that want to help you is one thing, and then chasing down the people that actually can help you is a completely different one. That was for me the most challenging bit, getting actually, to know who can do what and getting, yeah in the end, getting access to the actual machines, the whole ecosystem is running on that was really heavy.


    Derick Rethans 2:34

    The System Administration of PHP.net systems is very fragmented. There's some people having access to some machines and some other people having access to other machines and yea it sometimes takes some time to track down where are all these bits actually run.


    Andreas Heigl 2:51

    One thing is getting tracking down, where the bits run, the other one is, there is an excellent documentation in the wiki, the PHP wiki, which in some parts is kind of outdated. The other thing is, if you don't actually address the different people themselves personally, it is like screaming into the void so you can can send an email to 15 different people that have access to a box, like someone needs to do this and this and this. And everyone kind of seems to think, yeah, someone else can do that. I just don't have the time at this point in time Things get delayed, so you're waiting for an answer for a week; you do some other stuff, so tw

    PHP Internals News: Episode 77: fsync: Buffers All The Way Down

    PHP Internals News: Episode 77: fsync: Buffers All The Way Down

    PHP Internals News: Episode 77: fsync: Buffers All The Way Down


    London, UK

    Thursday, February 25th 2021, 09:05 GMT



    In this episode of "PHP Internals News" I chat with David Gebler (GitHub) about his suggestion to add the fsync() function to PHP, as well as file and output buffers.

    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:13

    Hi, I'm Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is Episode 77. In this episode I'm talking with David Gebler about an RFC that he's written to add a new function to PHP called fsync. David, would you please introduce yourself?


    David Gebler 0:35

    Hi, I'm David. I've worked with PHP professionally among other languages as a developer of websites and back end services. I've been doing that for about 15 years now. I'm a new contributor to PHP core, fsync is my first RFC.


    Derick Rethans 0:48

    What is the reason why you want to introduce fsync into the PHP language?


    David Gebler 0:52

    It's an interesting question. I suppose in one sense, I've always felt that the absence of fsync and some interface to fsync is provided by most other high level languages, has always been something of an oversight in PHP. But the other reason was that it was an exercise for me in familiarizing myself with PHP's core getting to learn the source code, and it's a very small contribution, but it's one that I feel is potentially useful, and it was easy for me to do as a learning exercise.


    Derick Rethans 1:16

    How did you find learning about PHP's internals?


    David Gebler 1:19

    Quite the roller coaster. The PHP internals are very arcane I suppose I would say, it's it's something that's not particularly well documented. It's quite an interesting challenge to get into it. I think a lot of it you have to pick up from digging through the source code, looking at what's already been done, putting together the pieces, but there is a really great community on the internals list, and indeed elsewhere online, and I found a lot of people very helpful in answering questions and again giving feedback when I first opened my initial proof of concept PR


    Derick Rethans 1:48

    Did you manage to find room 11 on Stack Overflow chat as well?


    David Gebler 1:52

    I did not, no.


    Derick Rethans 1:53

    I'll make sure to add a link in the show notes and it's where many of the PHP core contributors hang out quite a bit.


    David Gebler 2:00

    Sounds good to know for the future.


    Derick Rethans 2:02

    I read the RFC earlier today. And it talks about fsync, but it also talks about flush, or f-flush. What is the difference between them and what does fsync actually do?


    David Gebler 2:14

    That's the question that will be on everyone's lips when they hear about this feature being introduced into the language, hopefully. What does fsync do and what does fflush do? To understand that we have to understand the concept of the different types of buffering, an application runs on a system. So we have the application or sometimes called the user space buffer, and we have the operating s

    PHP Internals News: Episode 76: Deprecate null, and Array Unpacking

    PHP Internals News: Episode 76: Deprecate null, and Array Unpacking

    PHP Internals News: Episode 76: Deprecate null, and Array Unpacking


    London, UK

    Thursday, February 18th 2021, 09:04 GMT



    In this episode of "PHP Internals News" I chat with Nikita Popov (Twitter, GitHub, Website) about two RFCs: Deprecate passing null to non-nullable arguments of internal functions, and Array Unpacking with String Keys.

    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. This is Episode 76. In this episode, I'm talking with Nikita Popov about a few more RFCs that he has been working on over the past few months. Nikita, would you please introduce yourself.


    Nikita Popov 0:34

    Hi, I'm Nikita. I work on PHP core development on behalf of JetBrains.


    Derick Rethans 0:39

    In the last few PHP releases PHP is handling of types with regards to internal functions and user land functions, has been getting closer and closer, especially with types now. But there's still one case where type mismatches behave differently between internal and user land functions. What is this outstanding difference?


    Nikita Popov 0:59

    Since PHP 8.0 on the remaining difference is the handling of now. So PHP 7.0 introduced scalar types for user functions. But scalar types already existed for internal functions at that time. Unfortunately, or maybe like pragmatically, we ended up with slightly different behaviour in both cases. The difference is that user functions, don't accept null, unless you explicitly allow it using nullable type or using a null default value. So this is the case for all user types, regardless of where or how they occur as parameter types, return values, property types, and independent if it's an array type or integer type. For internal functions, there is this one exception where if you have a scalar type like Boolean, integer, float, or a string, and you're not using strict types, then these arguments also accept null values silently right now. So if you have a string argument and you pass null to it, then it will simply be converted into an empty string, or for integers into zero value. At least I assume that the reason why we're here is that the internal function behaviour existed for a long time, and the use of that behaviour was chosen to be consistent with the general behaviour of other types at the time. If you have an array type, it also doesn't accept now and just convert it to an empty array or something silly like that. So now we are left with this inconsistency.


    Derick Rethans 2:31

    Is it also not possible for extensions to check whether null was passed, and then do a different behaviour like picking a default value?


    Nikita Popov 2:40

    That's right, but that's a different case. The one I'm talking about is where you have a type like string, while the one you have in mind is where you effectively have a type like string or null.


    Derick Rethans 2:51

    Okay.


    Nikita Popov 2:52

    In that case, of course, accepting null is perfectly fine.


    Derick Rethans 2:56

    Even though it might actually end up being different defaults.


    Nikita Popov 3:01

    Yeah. Nowadays we would prefer to instea

Top Podcasts In Technology

Listeners Also Subscribed To