Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:20401 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3940 invoked by uid 1010); 25 Nov 2005 13:25:06 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 3878 invoked from network); 25 Nov 2005 13:25:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2005 13:25:05 -0000 X-Host-Fingerprint: 66.249.82.194 xproxy.gmail.com Linux 2.4/2.6 Received: from ([66.249.82.194:51073] helo=xproxy.gmail.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id AC/70-56276-72B07834 for ; Fri, 25 Nov 2005 08:01:27 -0500 Received: by xproxy.gmail.com with SMTP id t10so479264wxc for ; Fri, 25 Nov 2005 05:01:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mPT9Ovx1AnvoBNLHYfOpzbGPk4kFG14sGkMwdk7ikJgj0DKrWbS+xRdU7rX+cMXDl0SqLUyROSeBqZsZUtcnnPM5aaa7W5fjcH2TTbQwRSqL2yRSopPiIfyW1hb07xKtFUFg0UJlt+JcV/9w2AjqN/i4iL/1rUrdgj7hEutvo28= Received: by 10.70.88.3 with SMTP id l3mr6185171wxb; Fri, 25 Nov 2005 05:01:25 -0800 (PST) Received: by 10.70.10.7 with HTTP; Fri, 25 Nov 2005 05:01:24 -0800 (PST) Message-ID: <818043770511250501u330b5506m2db127e18cab081@mail.gmail.com> Date: Fri, 25 Nov 2005 14:01:24 +0100 Sender: sebastian.kugler@gmail.com To: Rasmus Lerdorf Cc: internals@lists.php.net In-Reply-To: <4386C97D.3030402@lerdorf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4386C97D.3030402@lerdorf.com> Subject: Re: [PHP-DEV] Fixing this date mess From: sk@webfactory.de (Sebastian Kugler) > This rename would also give us a migration path where you could have a > simple: class date extends date_ex { ... } wrapper which could then be > removed when we have the final internal date class implementation. IMVHO this is a good idea. At least I greatly appreciate that it wouldn't break applications just for the sake of having a namespace for constants and "future proofing". > I don't think having this mostly empty date > class placeholder helps anybody right now. It seems to for some people, but for the majority of PHP application developers out there it does the exact opposite. Regards, Sebastian