Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17179
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net
Date: Fri, 8 Jul 2005 02:17:23 +0200
Message-ID: <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
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] date/timezone classes
From: pierre@dotgeek.org (Pierre-Alain Joye)

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