Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28627
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <460ABFCC.2070702@lerdorf.com>
Date: Wed, 28 Mar 2007 12:19:40 -0700
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: "Mauro N. Infantino" <mauroi@digbang.com>
CC: internals@lists.php.net
References: <004001c77167$5d07a220$ec01010a@intranet.db>
In-Reply-To: <004001c77167$5d07a220$ec01010a@intranet.db>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Datetime problem
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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.
>