Post Script on POW

10 03 2014

Flickr: by Anders Sandberg (Arenamontanus)

The new pow operator ** has needed a little tweaking and at the same time we may need to rethink the usefulness of the pow().   From the outset, PHP developers learned that the ** would not perform identically to the pow() and that seemed acceptable.  But, maybe the original RFC should have advocated deprecating the pow() and replacing it with the ** operator.  In a previous post I explained why the following code produces different results (see “PHP on the Cusp of a New Operator“)

<?php
echo pow(-3,2);            // 9
echo -3 ** 2;              // -9
$a = -3;
echo $a ** 2;              // 9

I was willing to accept the foregoing, despite the discrepancies, because the convenience of using ** seemed well worth it.  Now, it seems pointless and confusing to have two ways of doing the same mathematical operation where the results may differ, depending on whether one uses the pow() or the ** operator.  Logic would dictate that one of these options needs to go.

The author of the RFC for the ** operator, reported in February that there was a memory leak associated with the pow(),  when its second parameter is an empty array in the upcoming PHP5.6.  According to Wikipedia , a memory leak is a common error in languages that lack default garbage collection such as C, which happens to largely provide the basis of PHP to date.  The article explains that a  memory leak typically involves memory that has been allocated dynamically and has become inaccessible.  This particular memory leak in PHP is now resolved but its manner of resolution results in yet another PHP inconsistency.  Consider the following results:

<?php
var_dump( pow(0,[]) ); // float 1.0 in PHP 5.5
var_dump( pow(0,[]) ); // int 1.0 in PHP 5.6

See http://3v4l.org/rB635

The fact that pow() in the upcoming PHP version returns an int instead of an expected float as PHP does currently in the preceding example, may have little impact on most users.  But, what if you happen to be the user that does get impacted?  It’s these kinds of design anomalies that can add up and over time lead to user dissatisfaction with what was once a language that sought to please its user base.

The latest news concerning the related ** operator, on the other hand, should be welcome to everyone.  In PHP5.6, one will be able to use that operator to define a constant.  Formerly a bug report detailed that such a feat was unachievable. Now, thanks to a PR (pull request) code like the following is valid in PHP5.6:

<?php
const FOO = 2 ** 3 ** 2;
echo FOO; // 512

(excerpted from  http://markmail.org/message/paok4hzqusxlp2ue)

At this point, I wonder if the best option might be to retire the pow() and have only the ** operator available, in order to eliminate the aforementioned gotcha and simplify using PHP.  A TIMTOWTDI (“There is more than one way to do it”) approach instead of offering pleasing flexibility, in this case lends itself to needless confusion and adds to the complexity of PHP.  Deprecating pow() in PHP5.7 and then deleting it from the language in PHP6 when one expects all sorts of BC (“backwards compatibility”) breaks, might make the most sense.

This work is licensed under a Creative Commons License

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: