Re: [PHP-DEV] date/timezone classes
Can we please wrap up the whole OO/non-OO discussion and just fix the damn ext/date so that it works as advertised? The rest can be done later. Let's not hold up RC1 unless really necessary. -Andrei On Jul 8, 2005, at 1:06 PM, Marcus Boerger wrote: Hello Derick, Friday, July 8, 2005, 2:31:14 PM, you wrote: On Fri, 8 Jul 2005, Edin Kadribasic wrote: I would love to be able to do something like this: $d = new Date(time()); $d-month++; $d-print(Y-m-d); // date() equiv. Adding methods is no problem, that's what you get for free anyway, I just think that $d-month is too much magic, and not reproducable in non OO. I wouldn't care for non oo here. And instead pretty much appreciate such stuff since it'd heavliy simplify working on calendar tools and still have nice readable code. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Hello Andrei, 1 Monday, July 11, 2005, 7:16:45 PM, you wrote: Can we please wrap up the whole OO/non-OO discussion and just fix the damn ext/date so that it works as advertised? The rest can be done later. Let's not hold up RC1 unless really necessary. -Andrei On Jul 8, 2005, at 1:06 PM, Marcus Boerger wrote: Hello Derick, Friday, July 8, 2005, 2:31:14 PM, you wrote: On Fri, 8 Jul 2005, Edin Kadribasic wrote: I would love to be able to do something like this: $d = new Date(time()); $d-month++; $d-print(Y-m-d); // date() equiv. Adding methods is no problem, that's what you get for free anyway, I just think that $d-month is too much magic, and not reproducable in non OO. I wouldn't care for non oo here. And instead pretty much appreciate such stuff since it'd heavliy simplify working on calendar tools and still have nice readable code. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Derick Rethans wrote: On Mon, 11 Jul 2005, Pierre-Alain Joye wrote: On Mon, 11 Jul 2005 10:16:45 -0700 Andrei Zmievski [EMAIL PROTECTED] wrote: Can we please wrap up the whole OO/non-OO discussion and just fix the damn ext/date so that it works as advertised? The rest can be done later. Let's not hold up RC1 unless really necessary. It's not a stopping for 5.1. This is not going to be in 5.1. We already agreed on that :) We did not. I implemented my specs now, including OO methods. Updated ones are attached. I agree with Andrei that we should not hold up 5.1 release with ext/date. We should IMHO release 5.1 with the working replacements of broken existing functions. Having datetime stuff working independent of the OS is an achievement in itself. As for the additional functionality I belive that more effort should be made to come up with a nice API for handling date/time. Pecl/date is a very good starting point in this direction and the effort that has been made there should not be wasted. As I said, it is the best in my oppinion to leave this for after 5.1 release. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Mon, 11 Jul 2005, Derick Rethans wrote: On Mon, 11 Jul 2005, Pierre-Alain Joye wrote: On Mon, 11 Jul 2005 10:16:45 -0700 Andrei Zmievski [EMAIL PROTECTED] wrote: Can we please wrap up the whole OO/non-OO discussion and just fix the damn ext/date so that it works as advertised? The rest can be done later. Let's not hold up RC1 unless really necessary. It's not a stopping for 5.1. This is not going to be in 5.1. We already agreed on that :) We did not. I implemented my specs now, including OO methods. Updated ones are attached. Patch is here: http://files.derickrethans.nl/patches/date-2005-07-12.diff.txt Also fixes a bug parsing 11Oct and adds some constants with commonly used formats. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Guys, I definitely think that the path to 5.1 currently has to focus on PDO and the ZE stabilizing. I plan to release Beta 3 hopefully tomorrow (a bit late because I'm still waiting for some PDO fixes Wez wants to make). Commiting a new Date extension at this point is definitely high risk. Derick probably wouldn't agree if it were someone else :) I personally would prefer this work to be done in PECL and roll them into HEAD once they have stabilized. As it's new functionality it could also be in a mini release (5.1.1, 5.1.2) which will surely follow quickly after 5.1.0. I don't see why we need to be in such a rush... There is no reason this won't get out to the masses. As it is, it was questionable wether my call to allow changing the core Date functions at such a late time in the game was a good call by me. Andi At 12:27 AM 7/12/2005 +0200, Derick Rethans wrote: On Mon, 11 Jul 2005, Derick Rethans wrote: On Mon, 11 Jul 2005, Pierre-Alain Joye wrote: On Mon, 11 Jul 2005 10:16:45 -0700 Andrei Zmievski [EMAIL PROTECTED] wrote: Can we please wrap up the whole OO/non-OO discussion and just fix the damn ext/date so that it works as advertised? The rest can be done later. Let's not hold up RC1 unless really necessary. It's not a stopping for 5.1. This is not going to be in 5.1. We already agreed on that :) We did not. I implemented my specs now, including OO methods. Updated ones are attached. Patch is here: http://files.derickrethans.nl/patches/date-2005-07-12.diff.txt Also fixes a bug parsing 11Oct and adds some constants with commonly used formats. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Thu, 7 Jul 2005, Andi Gutmans wrote: 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). Objects are not harder to implement, I found it actually more straight forward. Besides that, making it an object allows other people to extend it, something that Pierre wants for his pecl/date. 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); Those are not equivalent. $date-getOffset(); vs. date_offset_get($date); 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. ? The way how they expose datatypes doesn't really differ. It's just that *currently* I've no plans to add fancy methodnames. All other functions on standard datatypes work with functions. This falls IMO in the same category as not wanting a full blown String class in the core of PHP. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Fri, 8 Jul 2005 09:16:29 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: Objects are not harder to implement, I found it actually more straight forward. Besides that, making it an object allows other people to extend it, something that Pierre wants for his pecl/ date. I do not want to extend a basic date object. This adds overheads for nothing. pecl/date was originally designed to be integrated in php, see: http://marc.theaimsgroup.com/?l=php-devm=104540995515576w=2 Integrate it in ext/date, keeping full BC with existing functions as they do not change. When the implementations reach a stable state, we could have been able to use it inside the current functions and move them to ext/date. By the way, an object with basic method/properties and more advanced methods/ properties will not consume more memory, will not add overhead to people who does not want to use an object. ? The way how they expose datatypes doesn't really differ. It's just that *currently* I've no plans to add fancy methodnames. All other functions on standard datatypes work with functions. This falls IMO in the same category as not wanting a full blown String class in the core of PHP. Even if I agree on you about a String class, you miss the point. A 12k buffer upper cased with current functions ends with 2x 12k buffers. About a date/time object, these values have much more properties. It is slighty more difficult to deal with them (non linear, exceptions, etc.). People needs to work with ranges, arythmetics. They also need some simple (and fast) function to get informations other than the current properties. Another additions are iterators, filtered iterators are a killing feature for people having to create complex calendar applications. a complex calendar applications is something else that the current month calendar displayed on every single blog out there. But words are sometimes useless, I will put my thoughts in pecl/ date. This is a perfect place to make experiments on an usefull APIs and get feedbacks. Once we (not only you and me but everyone having some clue) agree on the features and the specifications, we can then put in ext/date. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Friday 08 July 2005 02:17, Pierre-Alain Joye wrote: [snip] 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 agree that it would be a great idea to have a common Date object in PHP. And since most of it is already implemeted by the new timelib and the existing object code in PECL/date I see no reason not merge that in core date module. I would love to be able to do something like this: $d = new Date(time()); $d-month++; $d-print(Y-m-d); // date() equiv. And implement all other datetime functions in similar matter. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Fri, 8 Jul 2005, Edin Kadribasic wrote: I would love to be able to do something like this: $d = new Date(time()); $d-month++; $d-print(Y-m-d); // date() equiv. Adding methods is no problem, that's what you get for free anyway, I just think that $d-month is too much magic, and not reproducable in non OO. (Also, passing a timestamp with time() is not always working, because of windows' limitations with it, that's the reason why I made it a string, or empty in case you want to use current time). Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Fri, 8 Jul 2005 14:31:14 +0200 (CEST) Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 8 Jul 2005, Edin Kadribasic wrote: I would love to be able to do something like this: $d = new Date(time()); $d-month++; $d-print(Y-m-d); // date() equiv. Adding methods is no problem, that's what you get for free anyway, I just think that $d-month is too much magic, and not reproducable in non OO. (Also, passing a timestamp with time() is not always working, because of windows' limitations with it, that's the reason why I made it a string, or empty in case you want to use current time). for the current time, it's fine. For example getting the next monday is pretty easy using this way. Properties are not magic. Thier behiavors have to be well documented. And how they work discussed. I talked a bit with Derick on IRC. I will take some times to finalize the specifications and put them online. We can then have a document to talk about. Not like I like to talk endlessly but there is issues we have to agree on before any implementation. Expect it over the weekend. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
At 02:36 PM 7/8/2005 +0200, Pierre-Alain Joye wrote: On Fri, 8 Jul 2005 14:31:14 +0200 (CEST) Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 8 Jul 2005, Edin Kadribasic wrote: I would love to be able to do something like this: $d = new Date(time()); $d-month++; $d-print(Y-m-d); // date() equiv. Adding methods is no problem, that's what you get for free anyway, I just think that $d-month is too much magic, and not reproducable in non OO. (Also, passing a timestamp with time() is not always working, because of windows' limitations with it, that's the reason why I made it a string, or empty in case you want to use current time). for the current time, it's fine. For example getting the next monday is pretty easy using this way. Properties are not magic. Thier behiavors have to be well documented. And how they work discussed. I talked a bit with Derick on IRC. I will take some times to finalize the specifications and put them online. We can then have a document to talk about. Not like I like to talk endlessly but there is issues we have to agree on before any implementation. Expect it over the weekend. Great. I definitely think you two should work together on this one. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Hello Derick, Friday, July 8, 2005, 2:31:14 PM, you wrote: On Fri, 8 Jul 2005, Edin Kadribasic wrote: I would love to be able to do something like this: $d = new Date(time()); $d-month++; $d-print(Y-m-d); // date() equiv. Adding methods is no problem, that's what you get for free anyway, I just think that $d-month is too much magic, and not reproducable in non OO. I wouldn't care for non oo here. And instead pretty much appreciate such stuff since it'd heavliy simplify working on calendar tools and still have nice readable code. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Hello Pierre-Alain, since we now have ext/date shouldn't we rename pecl/date to something different for easier integration? And i also do not know if we aren't running into problems later if two extensions have the same name. marcus Friday, July 8, 2005, 12:44:45 PM, you wrote: On Fri, 8 Jul 2005 09:16:29 +0200 (CEST) [EMAIL PROTECTED] (Derick Rethans) wrote: Objects are not harder to implement, I found it actually more straight forward. Besides that, making it an object allows other people to extend it, something that Pierre wants for his pecl/ date. I do not want to extend a basic date object. This adds overheads for nothing. pecl/date was originally designed to be integrated in php, see: http://marc.theaimsgroup.com/?l=php-devm=104540995515576w=2 Integrate it in ext/date, keeping full BC with existing functions as they do not change. When the implementations reach a stable state, we could have been able to use it inside the current functions and move them to ext/date. By the way, an object with basic method/properties and more advanced methods/ properties will not consume more memory, will not add overhead to people who does not want to use an object. ? The way how they expose datatypes doesn't really differ. It's just that *currently* I've no plans to add fancy methodnames. All other functions on standard datatypes work with functions. This falls IMO in the same category as not wanting a full blown String class in the core of PHP. Even if I agree on you about a String class, you miss the point. A 12k buffer upper cased with current functions ends with 2x 12k buffers. About a date/time object, these values have much more properties. It is slighty more difficult to deal with them (non linear, exceptions, etc.). People needs to work with ranges, arythmetics. They also need some simple (and fast) function to get informations other than the current properties. Another additions are iterators, filtered iterators are a killing feature for people having to create complex calendar applications. a complex calendar applications is something else that the current month calendar displayed on every single blog out there. But words are sometimes useless, I will put my thoughts in pecl/ date. This is a perfect place to make experiments on an usefull APIs and get feedbacks. Once we (not only you and me but everyone having some clue) agree on the features and the specifications, we can then put in ext/date. Regards, --Pierre -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
Since the underlying way of passing internal data would be an object, the functions you propose may as well be object methods. Aside from that the API looks good. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] date/timezone classes
Hei, I wrote up a little document about how I want to implement the date and timezone classes - although I'm not planning any OO methods. I'm just wrapping the timelib_time and timelib_tzinfo structures in an object. Let me know what you think. DerickDefinitions: Timezone Abbreviation: CEST, EEST, PDT Timezone Identifier: Europe/Oslo, Europe/Helsinki, America/Los_Angeles Timezone database: Database consisting of all timezone definitions and Transition Times. Transistion Time: Time where the GMT offset in a timezone changes (f.e. due to a DST changeover) Timezone related functions obj timezone timezone_open(string timezone); Loads a timezone from the database. First the timezone will be looked for in the Timezone Abbreviation database and the corresponding Timezone Identifier is then opened from the database. If the timezone is not found in the Timezone Abbreviation database, then the function attempts to load it directly from the Timezone database. string timezone_name_get(obj timezone); Returns the Timezone Identifier belonging to the timezone object. int timezone_offset_get(obj timezone, obj date); Returns the GMT offset belonging to the date object in the passed timezone. array timezone_transistions_get(obj timezone); Returns a multi-dimensional array containing all the known Transistion Times. Each element in the returned array consists of two elements. The first element time is a string in the format -mm-ddThh:ii:ssZ describing the transistion time, and the second element offset is the GMT offset accompanying the Transistion Time. array timezone_abbreviations_list(); Returns a multi-dimensional associate array where the key is the Timezone Abbreviation and as data an array with three elements: offset describes the GMT offset in seconds, dst whether the Timezone Abbreviation is a DST abbreviation or not and timezone_id containing the Timezone Identifier as string if it exists, or NULL otherwise. array timezone_identifiers_list(); Returns a single-dimensional array with all available Timezone Identifiers as string. Date related functions obj date date_create(string date_representatation); Creates a date object out of a string representation of date/time information - analogous to strtotime(). obj timezone date_timezone_get(obj date); Returns the timezone object associated with the date object. Returns false if the time was not a local time, but UTC time. int date_offset_get(obj date); Returns the offset in seconds that belongs to the time that the date object represents in the assigned timezone. If the date is currently representing UTC time, then 0 will be returned, and if the date is representing a local time then the offset to UTC will be returned. bool date_timezone_set(obj date, obj timezone); Updates the date object's timezone with the passed timezone object. Returns true if this succeeded, or false when it doesn't (which I can't find a reason for why that might happen right now). bool date_timezone_set_by_name(obj date, string timezone); Updates the date object's timezone with the passed timezone string. The same algorithm for determining the Timezone Identifier is used as when creating a timezone object with timezone_open(). Returns false if the timezone could not be found, true if everything went Ok. bool date_to_utc(obj date); Unassociates the timezone information from the date, reverting it to UTC time. Returns true if there was something changed, false if the date object was already representing UTC time. bool date_to_local(obj date); Associates the timezone information already available in the date object with the date object again. This results in the representation using the local time with an offset to UTC again. Returns true if there was something changed, false if the date object was already representing local time. string date_format(date obj, string format) Formats a date with the format string format. The same format modifiers are being used as with the date() function. bool date_modify(date obj, string modify_string) Uses strtotime() functionality for modifying the date object. An example of such a modifying string is next month. If an invalid format is passed, false will be returned, otherwise the date will be modified and true returned. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
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); 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. 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. Andi At 11:10 PM 7/7/2005 +0200, you wrote: Hei, I wrote up a little document about how I want to implement the date and timezone classes - although I'm not planning any OO methods. I'm just wrapping the timelib_time and timelib_tzinfo structures in an object. Let me know what you think. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date/timezone classes
On Thu, 07 Jul 2005 16:56:51 -0700 [EMAIL PROTECTED] (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
Re: [PHP-DEV] date/timezone classes
On Jul 7, 2005, at 7:56 PM, Andi Gutmans wrote: It would look the following: $timeZone-getName(); vs. date_timezone_get($date); $date-getOffset(); vs. date_offset_get($date); 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. 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. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 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 [EMAIL PROTECTED] (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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
