What PHP extension would you make yourself, or do you need?

As I have not seen any discussion on this subject for a while, and as the whole web environment has evolved in directions we may not have imagined since then - I thought I’d ask you.

If you could make any PHP extension in C what would it be, and what would it do? (I hasten to add that making such a thing is beyond my skills).

Writing extensions
Extending PHP

To save reading either of the above you could think of an extension as being a native PHP function, such as strlen(), but instead of having to write it yourself and having to include() the code for it - once written in C and compiled into your own PHP code you just call it and it magically appears.

I’m especially interested in hearing about the challenges that new technologies seem to be foisting upon us, mobile, svg, html5 maybe Ajax and so on, but feel free to add any whimsical “missing” functions (which is my memory of the last discussions).

I find this ***t really ugly:

$email = (isset($email)) ? $email : '' ;

Don’t get me wrong I think the ternary operator is a smart shorthand thing, but I seem to have too many of them - I acknowledge this might be a sign of other weaknesses in my code, but I digress …

In reality they are more likely to look something like:

$user->email = ( isset($_POST['email']) ) ? $_POST['email'] : false ;

Sometimes this line can stretch on quite a ways, and it seems to contravene DRY as I am often typing the same var name twice.

so what about a function that set a var if it is not set at that point.

setit($_POST['email'], false);

Behind the scenes it checks to see if $_POST[‘email’] has been set and if it has not add it and give it the default value, false.

Or does something like this exist and I have not seen (or not understood) it?

$email = $_POST['email'] ?: false;

PHP 5.3+, and incredibly awesome :slight_smile:

I think ?: acts more like empty() than isset(), but for 90% of cases that should suffice.

Allow me to interject and say that from a strictly typed stand-point that would make little sense.If email is expected to be a string than it should always be assigned to a string. At least that is what I would expect. Either that or assign it to null, not false – false is a value. Therefore, null would be more appropriate.

$user->email = ( isset($_POST['email']) ) ? $_POST['email'] : null; 

If you wanted to know whether an email existed it would be a separate variable or method.

$user->hasEmail = $this->email !== null;


public function hasEmail() {
     return $this->email !== null;

This one is a new to me interesting.

$email = $_POST['email'] ?: false; 

Interestingly the initial proposal of PHP was to create a function (like Cups says, only they would name it ifsetor – horrible name) but it ended up a change in the ternary operator (like Immerse says) :slight_smile:

Minutes PHP Developers Meeting

Yeah, I remember reading those notes a while back. I think there were some heated discussions about it!

Maybe my example is a poor one, this is more strictly typed:

$email = $_POST['email'] ?: '' ;


What I’d like to see is to have external resources (esp database result sets) values converted to their correct data type. So an INT should be an integer in PHP too, not a string. A FLOAT should be a float too etc.
I’m sure there’s probably lots of good reasons for this not to happen. If so please enlighten me :slight_smile:

$email = $_POST['email'] ?: false; 

Well, another benefit of moving to 5.3, thanks.

… ifsetfor() and some more ideas of what it could do and adding filtering too.

I like that - from 2005, eh?

Except in the particular case I had in mind where I want to put the ‘email’ back into the $_POST array - i.e. not reassigning it.

I am processing the whole array like so:


So I’d still be doing:

$_POST['email'] = $_POST['email'] ?: false; 

(I accept that arguably I should unset($_POST[‘email’]) if it is empty and be making sure that the database had a default setting of null for this particular missing element)


Just noticed this: