php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #14782 key_exists renamed to array_key_exists
Submitted: 2001-12-31 15:33 UTC Modified: 2002-01-02 11:10 UTC
From: mike at newfangled dot com Assigned: zak (profile)
Status: Closed Package: Feature/Change Request
PHP Version: 4.1.1 OS: all
Private report: No CVE-ID: None
 [2001-12-31 15:33 UTC] mike at newfangled dot com
I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking.

Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken?


Thank you

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-31 16:21 UTC] zak@php.net
Hi Mike,

Unless one of the developers objects, I will add the alias 
- however, if the change is made, it would not show up 
'til the next release.

I would recommend that you modify your files anyway. It is 
a small amount of work using gawk or vim. :)

Alternately, you can modify your local copy of PHP until 
next release.

Add the following line to ext/standard/basic_functions.c:
  PHP_FALIAS(key_exists, array_key_exists, NULL)

The line should go after the line that looks like:
  PHP_FE(array_key_exists,        NULL)

Once you have made the change and saved, recompile PHP.



 [2001-12-31 16:37 UTC] zak@php.net
Assigning to myself

 [2001-12-31 16:59 UTC] zak@php.net
As "Someone Who Shall Not Be Named Because They Are Also 
On Vacation" has pointed out to me off list, it would be a 
bad thing to have functions disappearing and reappearing 
between versions. The function shall stay as is - please 
adjust your scripts accordingly.

Thank you.

 [2002-01-02 11:10 UTC] mike at newfangled dot com
I understand the issue or having functions disappear and then reappear..


We are a application service provider. We provide a content management system and application framework written in PHP to our customer's who host their sites on our colocated server at Rackspace. Just about every customer is running different version of our application. 

To migrate from one version to another is not just a file copy. It involves data base migration and changes and also application config changes. All our sites on our server are using PHP 4.0.6. To load PHP 4.1.1 means I have to bring all my sites down, load php 4.1.1, migrate the data, update each customer's config for the new app and then test each site. This is a huge undertaking. The way we normally handle application upgrades is to upgrade the customer's site the next time that their site comes in for maintenance work. I can understand that changing a function in a single site's scripts is not much of an issue, but please consider what this means to an ISP/ASP that is running many, possibly hundreds of sites. How an ISP will break many sites by loading PHP 4.1.1.

Our latest version of our app uses the key_exists() function. The funciton is what was needed for the problem at hand. I had no idea that a PHP function could suddenly become an "invalid function" in the next release of the language.  I can understand how an API can be retired. It out lived it's purpose or was buggy, but not function name.

I understand the naming consistancy problem that key_exists had, but architecturly how does it hurt the PHP to keep an alias for it? You could keep the alias and then put a warning on the www.php.net/key_exists page saying that the array_key_exists function should be used instead and that the key_exists function. Does an alias affect performance or the memory foot print of PHP? Is it just a pointer to the correct function?

Please understand that I am arguing this point to protect PHP and my company's investment. My company has based it's current and future success on the reliability, consistancy, performance, and power of PHP. 

Please make these kind of decisions more cautiously with larger more complex PHP applications and ISP/ASPs in mind.

Thank you for your response and concern on these issues.

Mike Boulet
Newfangled Web Factory
www.newfangled.com

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 04:01:28 2024 UTC