Re: date/timezone classes

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