Can a user-defined function override a built-in function?

[cmayo]

Hi all,

I've just moved my coding environment to a new server which is running PHP 5 (previous server ran 4.x), and my current project includes a user-defined function date_format().

As it turns out, PHP 5 now has a date_format() function of its own and all my calls to the original user function are now going to PHP's built-in function, thus breaking my code.

I'm not holding out much hope for this, but can anyone suggest a way that I could have my code use the user function instead of the built-in without renaming the user function and editing all the calls?

 

[DonQuichote]

you may be able to blacklist the date_format function in your PHP.ini file. This feature is meant to be able to switch off any security sensitive function. But that is a very dirty hack. Editing the calls is really much, much better...

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[cmayo]

DonQuichote, good thought. I hadn't known about PHP's disable_fuctions directive and my Googling led to a bunch of good stuff about tightening PHP that I really need to read, but...

Even though I can disable date_format in php.ini, PHP won't let me redeclare the date_format() function.

Agreed about the dirty hack, but I've been down for three weeks while moving my dev VPS to a new host (why do these ISPs always make me wonder if mine is the first VPS they ever set up? Does anyone ever build a clean VPS on the first try?), my client's getting impatient, and I don't think I can sell the time I'll have to spend to rewrite the code because his server's still on PHP 4.x where there's no conflict.

So unless anyone else has any ideas, I guess my choice is to downgrade my own PHP to 4.x (which I hate to do 'cuz it's taken me three weeks to get them to configure PHP 5 correctly and still doesn't solve the problem long-term), or bite the bullet and start rewriting code. Oh well... if it was easy, anyone could do it.

Thanks again for the suggestion,

Chuck

 

[jpadie]

cmayo - the best answer is to include the function within a class. i.e. make it a method. that way the encapsulation works ok.

then use aptana or some other tool to do a global search and replace.

despite donQ being 100% correct, unloading functions from the php core can't be a good thing for portability/maintenance etc.

 

[cmayo]

Jpadie, I have to confess that even after coding PHP for years, I still don't really grok classes and methods. If I had my way, I'd still be writing GOTOs and GOSUBs in BASICA on a DOS box.

I didn't know about Aptana, but I eentualy remembered that I had a little search & replace PERL script that a buddy wrote for me years ago, and I ran it against all the project files and that seems to have done the trick.

I really appreciate you guys - thanks a lot.

Chuck

 

[jpadie]

at it's simplest

class replacementFunctions{
  public function date_format($input){
    //do something
    //return something
  }
}

then to use it

$format = replacementFunctions::date_format($someinput);

or more neatly perhaps

$rf = new replacementFunctions();
$format = $rf->date_format($someinput);

 

[cmayo]

Jpadie, thanks again. I can see how that would allow a user-defined function with the same name as a built-in, but I'd still have had to recode all the 150+ function calls, and that was really more the problem in this case than just renaming the functions themselves.

Your example makes it easy to see how to employ classes and methods, but I've always wondered about the 'why' of using them, and maybe my problem this week is a good example of that.

If all the user functions had been encapsulated in a class, then all the function calls would've already been written to call that class' specific version of date_format() and the app wouldn't have broken when PHP 5 intruduced its built-in date_format(), nor would it break if another block of code or class or later add-on module introduced its own version of date_format()... they'd all be separate entities.

Is that the primary advantage of using classes and methods, or am I missing a bigger picture?

 

[jpadie]

i'd be happy to provide a script to make the alterations automagically if that is useful to you.

the discussion on procedural code vs object code is long running. i was a late convert to classes/objects but i now see the benefits of inheritance and encapsulation and use them regularly. particularly for coding things like wordpress plugins where you need to make totally sure that your function namespace is not going to clash with anyone elses.

 

[theEclipse]

they'd all be separate entities.

Is that the primary advantage of using classes and methods, or am I missing a bigger picture?

...that is the benefit of encapsulation.

To my knowledge, the primary reason for the invention of classes/methods in the first place is simplistic data management. Encapsulation is, to my knowledge, a technique that evolved later as a way to (as jpadie said) "make totally sure that your function namespace is not going to clash with anyone elses" in languages that do not support namespacing.

Which is better? If you were to get 11 developers in a room and ask, you would probably get at least 13 differing opinions....

Robert Carpenter
Remember....eternity is much longer than this ~80 years we will spend roaming this earth.
ô¿ô

http://www.robertcarpenter.net

 

[cmayo]

Sorry for the tardy response... too many irons in the fire just now.

Jpadie, that'd be great and I'd appreciate having another useful tool at my disposal, thank you. I've done just enough OOP in other technologies to have the gist of object-oriented coding, and I think I'll try to implement classes/objects in my next small project.

Robert, I appreciate your comments. It seems the world is determined to make procedural coding obsolete in favor of object-oriented programming. But then again, the virtues of OOP have been extolled for decades and procedural is still very much alive, at least in the PHP world (PERL seems to have made the jump - I can hardly read a line of PERL code anymore).

I'm not sure I'm ready to jump fully onto that bandwagon but I do think it's time I got my feet wet. Simply from a "how much work is required to achieve a desired result" point of view, I haven't seen a lot of difference between procedural and OOP, but I'll grant that having so little OOP experience really doesn't put me in a very good position to make that judgment.