Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17184
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050707181248.02817020@localhost>
Date: Thu, 07 Jul 2005 18:13:36 -0700
To: Pierre-Alain Joye <pierre@dotgeek.org>,internals@lists.php.net
In-Reply-To: <20050708021723.46bb4484.pierre@dotgeek.org>
References: <Pine.LNX.4.62.0507072305500.17565@localhost>
	<5.1.0.14.2.20050707164528.02833cc0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] date/timezone classes
From: andi@zend.com (Andi Gutmans)

I think what makes most sense is for you two to work together on this. 
Again, I am more than happy to contribute.
Andi

At 02:17 AM 7/8/2005 +0200, Pierre-Alain Joye wrote:
>On Thu, 07 Jul 2005 16:56:51 -0700
>andi@zend.com (Andi Gutmans) wrote:
>
> > Hey Derick,
> >
> > If you're just wrapping the date type with a class, I don't see
> > why it shouldn't be a resource. It'd give you the same thing but
> > would be easier to implement (unless I'm missing something).
> > I realize you personally aren't fond of OO but it actually would
> > work very nicely with a Date class. I'm not talking about OO as
> > in over-architecting and having a huge hierarchy but just having
> > easy to use methods on the Date/TimeZone classes (one simple
> > level).
> >
> > It would look the following:
> >
> > $timeZone->getName();
> > vs.
> > date_timezone_get($date);
> >
> > $date->getOffset();
> > vs.
> > date_offset_get($date);
>
>I fully agree with that. I'm not a OO fanatic (meaning using OO for
>every little variable around) but date/time values are perfect
>candidate for objects (see pecl/date again for example).
>
>Object properties fetching are fast if well implemented. They allow
>to easily create loops and other steped operations.
>
>This kind of API was also why I asked to add TZ aliases support.
>Having 2 tables and a double lookup is not really a good idea ;).
>
>
>
> > Personally, unrelated to OO I think it's a nicer and cleaner way
> > of exposing such an API. It would also make it easier for some of
> > the other new extensions like SimpleXML, SOAP, PDO , etc. to take
> > advantage of it when exposing data types.
>
>This is what I talk about when I say a common Date object in php.
>Derick exported the headers on my demand, this is a good first step.
>
> > I think this should be seriously considered. I'll be happy to
> > work with you on this if it makes sense to you and others.
> > I think that this functionality is best to be developed in
> > parallel to 5.1. As it would be new unrelated functionality, I
> > think we could introduce it in 5.1.x after 5.1.0 is out and once
> > everyone feels comfortable with it. I don't think rushing it into
> > 5.1.0 is a good idea especially if my feedback is considered.
>
>If the 5.1.x that will have that is not too close from 5.1 (new job
>on 8th august...), I have some really good additions, they are
>nearly all unit tested, remains some doc ;). I will commit part of
>it in the next weeks (minus TZ as it conflicts with Derick's one...)
>
>As I said in another post, I do not have either the time or the
>motivations to port everything to ext/date. I partially disagree on
>some design choices and pecl/date has been totally ignored by
>Derick, that does not help :).
>
>Having the current code in 5.1.0 for some weeks will help to fix it
>and find possible issues, errors, or needs requested by extension
>developers. Then we can safely add this new API as experimental for
>the 1st release. Once everyone agrees (or no one complained), we
>will freeze it.
>
>Regards,
>
>--Pierre
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php