This isn't going to change. But you can rename it yourself in ext/date/php_date.c. Just look for:
INIT_CLASS_ENTRY(ce_date, "DateTime", date_funcs_date); And put whatever name you want there. -Rasmus Mauro N. Infantino wrote: > Hi all, > > I know I've asked this before, but I couldn't find a solution (I'm not > asking for an easy one, just a viable solution). In my last email I didn't > include the reasons for my request, so I'll write them now. > > When we started with PHP5 there were no built-in PHP classes. This logically > means that there was no guideline for class prefixing other than the > programmers criteria. At that moment, and I still regret, we decided to > build a framework using non prefixed classes because we thought it was more > elegant. As usual, with the years, this framework got installed with each > application in maybe hundreds of servers. Also, hundreds of applications > refer to those class names. > > Right now, we want to upgrade to PHP5.2 in order to get all the benefits > from it. But we just can't modify and test all that codebase. I don't mean > it's impossible, it's just so difficult for a kind of upgrade that in > previous versions of PHP was really really easy. Furthermore, I suppose that > in a few months we're going to have to work hard for PHP6. > > For the obviouse reasons, we've tried not to use classes in PHP4. When PHP5 > was released, we were pleased that we could finally use an OO approach. > Every application built before the PHP5 release was not migrated, but PHP4 > is still maintained! PHP5.1 doesn't. > > So, what I'm asking is a workaround to this problem that caught us without > any warning: adding an ini setting to prevent this class definition (the > date_register_classes function, in this case). I know it's a hack, but it's > for people that ended up in our situation, without any way to prevent it > (Reminder: when PHP5 was released there were almost no built-in classes). > Even if it's undocumented, it would be useful. I can send the patch if you > want. > > Thanks again, > Mauro. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
