Continue 2 : Latest php version (7.3) New Features

This entry was posted on Friday November 22, 2019

array_key_last(), array_key_first() 

As per version 5.6 of PHP, there are over 75 built-in functions that belong to the arrays category.

Despite the vast numbers of tools available, at the moment, if we need to retrieve the first or the last key of an array we have to get all the keys using array_keys() and only then go for the first or last values of the array.

Another way is to opt for end() or reset().

As you may know, all the methods just described modify the array pointer, which is something that (other than a resources consumer) you just may not want to do.

The RFC of the upcoming version proposed the introduction of four brand-new methods the were set to solve this issue.

The four methods were:

• array_key_first() 
• array_key_last() 
• array_value_first() 
• array_value_last() 

They work for both numeric and associative arrays.

Here is some example of a numeric one:

$reindeers = [

1 => “Rudolphi”,

2 =>  “Dasheri”,

3 =>  “Danceri”,

4 =>  “Pranceri”,

5 =>  “Vixeni”,

6 =>  “Cometi”,

7 =>  “Cupidi”,

8 =>  “Donneri”,

9 =>  “Blitzeni”];

$first = array_key_first($reindeers); // $first is equal to 1

$last = array_key_last($reindeers); // $last is equal to 9

This, instead, is an example of an associative array:

$reindeers = [

“Rudolphi” => 1,

“Dasheri” => 2,

“Danceri” => 3,

“Pranceri” => 4,

“Vixeni” => 5,

“Cometi” => 6,

“Cupidi” => 7,

“Donneri” => 8,

“Blitzeni” => 9];

$first = array_key_first($reindeers); // $first is equal to “Rudolph”

$last = array_key_last($reindeers); // $last is equal to “Blitzen”

The same would have worked for the other two functions illustrated in this chapter,  array_value_*.

Just to be clear, those functions have been refused with 18 nos and 15 yeses.

In my opinion, these two functions would have been useful as well but according to several web developers, in certain cases, the value returned would have been ambiguous.

Here is why:

$reindeers = [];

$first = array_value_first($reindeers ); // $first is equal to null

$last = array_value_last($reindeers );// $last is equal to null

An additional option that I came across while browsing on forums and talking to other web developers was to return a tuple like [$key => $value].

Even though this option will not be available on the new version, seeing the favorable responses, it might arrive with the following RFCs.

Since this is a function that did not exist before, there are not going to be any backward compatibility problems, the only issues arrive if you have created and you are using your own version of array_key_first() and 
array_key_last().

Same Site Cookie

Conveying a protected application should consistently be the fundamental focal point of each software engineer. 

One task that every one of us is looking consistently is to lessen the danger of CSRF and information spill assaults. 

Same-site treats proclaim that treats must be sent distinctly with a solicitation started from a similar area. 

This isn’t an official standard yet Google Chrome and a few of the best PHP structures as of now actualize it while Firefox and new form of different systems affirmed that they are intending to do as such.

Here is the support schema for same site cookie from caniuse.com

Currently, cookies are issued by the set-cookie header, and web developers can set a key-value pair alongside flags for the browser in order to agree if a cookie should be available or not.

This way of doing things allows for vulnerable access to CSRF attacks.

The new RFC additions are supposed to solve the problem in a non-breaking way by adding a new parameter and also modifying some main functions of the language.

• setcookie 
• setrawcookie 
• session_set_cookie_params 

setcookie($name [,$value [,$expire [,$path [,$domain [, $secure [,$httponly [,$samesite]]]]]]]);

Two ways were proposed.

Adding a new argument to the function or allowing an array of options for moving all the options of the cookies inside.

How it will work?

Two values can be added to the same-site flag present in the above functions

They are Lax and Strict.

Cookies that are using Lax will be accessible to a GET request that comes from another domain, while on the contrary Strict will not be accessible ti a GET request.

For instance, the header, when using the Lax flag, will look like this:

Set-Cookie: key=value; path=/; domain=example.org; HttpOnly; SameSite=Lax

Counting highlights that expansion security in the code appears to be an easy decision be that as it may, as usual, before choosing to apply them in our contents we have to appropriately assess the professionals and the cons of our decisions

The fundamental danger of utilizing the SameSite banner as an advantageous contention to those capacities is that it may never turn into an official standard.

This implies, in the long run, programs won’t acknowledge the banner.

On the off chance that this occurs and you have just executed it, it will bring about your applications being loaded down with garbage code that should be expelled.

My own recommendation is to hold on to perceive what will occur. On the off chance that this banner turns out to be progressively utilized and in the long run characterized as a standard, put it all on the line!

Talking about in reverse perfect changes, as the vast majority of the past changes found in this article, there will be no issue while executing it in your code.

Conclusion

As I foreseen, this new discharge doesn’t include breaking changes, since it is anything but another adaptation; which I accept is the correct method to make refreshes. 

PHP is making little yet ceaseless strides that enable it to advance and improve after some time in spite of the way that throughout the years individuals have changed to progressively popular programming dialects.