Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:20588 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49581 invoked by uid 1010); 26 Nov 2005 21:13:14 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 49564 invoked from network); 26 Nov 2005 21:13:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Nov 2005 21:13:14 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:36996] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 40/FC-56276-9EFC8834 for ; Sat, 26 Nov 2005 16:13:14 -0500 Received: from [192.168.11.3] (c-24-6-96-18.hsd1.ca.comcast.net [24.6.96.18]) (authenticated bits=0) by colo.lerdorf.com (8.13.5/8.13.5/Debian-3) with ESMTP id jAQLDAvg006942; Sat, 26 Nov 2005 13:13:10 -0800 In-Reply-To: <43884194.1020000@lsces.co.uk> References: <4387E97B.4040300@prohost.org> <4387FC1E.5050207@lerdorf.com> <43884194.1020000@lsces.co.uk> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID: Content-Transfer-Encoding: 7bit Cc: internals@lists.php.net Date: Sat, 26 Nov 2005 13:13:42 -0800 To: Lester Caine X-Mailer: Apple Mail (2.623) Subject: Re: [PHP-DEV] Solution to date issue in 5.1 From: andrei@gravitonic.com (Andrei Zmievski) It seems to me that the only usable method of "ring fencing" core classes for the long term is to use namespaces. However, the namespaces feature is a fairly large one and obviously will not be in 5.1. We can discuss its inclusion in 5.2, should it happen to come out, or in PHP 6, but we need to get out 5.1.1 _now_. - Andrei On Nov 26, 2005, at 3:05 AM, Lester Caine wrote: > I strikes me that there is a more subtle problem here which goes > beyond just renaming Date, since we have had a period where people ARE > building their own libraries with their own classes. So while the > current niggle is Date, any new core class can potentially cause a > problem. Before we have any movement forward, a agreed method of ring > fencing core classes has to be sorted out since this was not > implemented previously? >