Hi, I’m Derick, and this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 60. Today I’m talking with Eliot Lear about adding OpenSSL CMS supports to PHP. Hello Eliot, would you please introduce yourself.

Hi Derick, it’s great to be here. My name is Eliot Lear, I’m a principal engineer for Cisco Systems working on IoT security.

I saw somewhere on the internet, Wikipedia I believe that he also did some RFCs, not PHP RFC, but internet RFCs.

That’s correct. I have a few out there I’m a jack of all trades But Master of None.

The one that piqued my interest was the one for the timezone database, because I added timezone support to PHP a long long time ago.

That’s right, there’s a whole funny story about that RFC, we will have to save it for another time but there are a lot of heroes out there in the volunteer world, who keep that database up to date, and currently the they’re corralled and coordinated by a lovely gentleman by the name of Paul Eggert and if you’re not a member of that community it’s really a wonderful contribution to make, and they need people all around the world to send an information but I guess that’s not why we’re here today.

But I’m happy to chat about that at some other point in the future. Now today we’re talking about CMS support in OpenSSL and the first time I saw CMS. I don’t think that means content management system here.

No, it stands for cryptographic message syntax, and it is the follow on to earlier work which people will know as PKCS#7. So it’s a way in which one can transmit and receive encrypted information or just signed information.

How does CMS, and PKCS#7 differ from each other.

Actually not too many differences, the externally the envelope or the structure of the message is slightly better formed, and the people who worked on that at the Internet Engineering Task Force were essentially just making incremental improvements to make sure that there was good interoperability, good for email support and encrypted email, and signed email, and for other purposes as well. So it’s very relatively modest but important improvements, from PKCS#7.

How old are these two standards?

Goodness. PKCS#7, I’m not sure actually of how old the PKCS#7 is, but CMS dates back. Gosh, probably a decade or so I’d have to go look. I’m sorry if I don’t have the answer to that one,

A ballpark figure works fine for me. Why would you want to use CMS over the older PKCS#7?

Hi, I’m Derick, and this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 59. Today I’m talking with Nikita Popov about a few RFCs that he’s produced. Hello Nikita, how are you this morning?

Hey Derick, I’m great. How are you?

Not too bad, not too bad today. I think I made a decision to stop asking you to introduce yourself because we’ve done this so many times now. We have quite a few things to go through today. So let’s start with the bigger one, which is the named arguments RFC. We have in PHP eight already seen quite a few changes to how PHP deals with set up and things like that we have had an argument promotion in constructors, we have the mixed type, we have union types, and now named arguments, I suppose built on top of that, again, so what are named arguments?

Currently, if you’re calling a function or a method you have to pass the arguments in a certain order. So in the same order in which they were declared in the function, or method declaration. And what named arguments or parameters allows you to do is to instead specify the argument names, when doing the call. Just taking the first example from the RFC, we have the array_fill function, and the array_fill function accepts three arguments. So you can call like array_fill( 0, 100, 50 ). Now, like what what does that actually mean? This function signature is not really great because you can’t really tell what the meaning of this parameter is and, in which order you should be passing them. So with named parameters, the same call would be is something like: array_fill, where the start index is zero, the number is 100, and the value is 50. And that should immediately make this call, like much more understandable, because you know what the arguments mean. And this is really one of the main like motivations or benefits of having named parameters.

Of course developers that use an IDE already have this information available through an IDE. But of course named arguments will also start working for people that don’t have, or don’t want to use an IDE at that moment.

At least in PhpStorm, there is a feature where you can enable these argument labels for constants typically only. This would basically move this particular information into the language, but I should say that of course this is not the only advantage of having named parameters. So making code more self documenting is one aspect, but there are a couple couple more of them. I think one important one is that you can skip default values. So if you have a function that has many optional arguments, and you only want to say change the last one, then right now you actually have to pass all the arguments before the last one as well and you have to know: Well, what is the correct default value to pass there, even though you don’t really care about it.

If I remember correctly, there are a few functions in PHP’s standard library, where you cannot actually replicate the default value with specifying an argument value, because they have this really complex and weird kind