# Datetime problem

- Thread: https://externals.io/message/28626
- Original archive: https://news-web.php.net/php.internals/28626
- Started by Mauro N. Infantino on 2007-03-28T18:31:55+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #28626 — Mauro N. Infantino — 2007-03-28T18:31:55+00:00

URL: https://externals.io/message/28626#28626

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.

---

## #28627 — Rasmus Lerdorf — 2007-03-28T19:19:40+00:00

URL: https://externals.io/message/28626#28627 · In reply to: #28626

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.