Re: [PHP-DEV] rfc2616 datetime format?
On Mon, 4 Oct 2010, Pierre Joye wrote: On Mon, Oct 4, 2010 at 1:27 AM, Stas Malyshev smalys...@sugarcrm.com wrote: It looks like a sub optimal choice to have used string constants instead of integer. However it could be still possible to define new constants as numeric. It is then possible to do whatever needs to be done as post or pre ops for the respective constants. I'm not sure what integers have to do with it? The constants define date formats that are in common use, RFC2616 is one of the commonest on the web and we don't have a constant for it... I mean in ext/date and as a reply to Derick, not your request which is totally valid. A date time object has the timezone information. If the constants were integers, it would be very straightforward to do some operations before calling the formatting functions depending on a given predefined format. It should still be possible to do it by testing the string contents (strncmp), but that's not very clean. Stop talking about something you don't know anything about, please. Those constants are not *one* format letter, they are many. Maybe you could have tried this: echo DateTime::RFC822, \n; Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rfc2616 datetime format?
On Mon, Oct 4, 2010 at 10:42 AM, Derick Rethans der...@php.net wrote: On Mon, 4 Oct 2010, Pierre Joye wrote: On Mon, Oct 4, 2010 at 1:27 AM, Stas Malyshev smalys...@sugarcrm.com wrote: It looks like a sub optimal choice to have used string constants instead of integer. However it could be still possible to define new constants as numeric. It is then possible to do whatever needs to be done as post or pre ops for the respective constants. I'm not sure what integers have to do with it? The constants define date formats that are in common use, RFC2616 is one of the commonest on the web and we don't have a constant for it... I mean in ext/date and as a reply to Derick, not your request which is totally valid. A date time object has the timezone information. If the constants were integers, it would be very straightforward to do some operations before calling the formatting functions depending on a given predefined format. It should still be possible to do it by testing the string contents (strncmp), but that's not very clean. Stop talking about something you don't know anything about, please. Those constants are not *one* format letter, they are many. Maybe you could have tried this: echo DateTime::RFC822, \n; Maybe you could read what I wrote instead of replying in such stupid manner, that could lead the discussions in a constructive direction, thanks. Key parts were: 1. using integer makes such features easier to implement (basic good practice/programming 101) 2. use strncmp to compare the format (yes, strncmp supports many characters) 2. is bad as it has the side effects of applying to a format given manually even if one did not intend to use it this way, it could have BC issues but I'm not sure at all if such format exists. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rfc2616 datetime format?
On Mon, Oct 4, 2010 at 1:17 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I am afraid that would break craploads of applications, and become very confusing. That's why I said BC earlier. But it could work for new formats. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rfc2616 datetime format?
On Sun, 3 Oct 2010, Stas Malyshev wrote: The reason is that in order to format a DateTime object as GMT, it needs to be converted to GMT... and you can't simply do that with just a constant consisting of a string of format characters. I see what you mean and it makes sense, having constant may imply that you can use it with any date and get proper result... But RFC2616 is the one of the most used formats on the Web - actually, the format that is called COOKIE is not the one that should be used in cookies - RFC2616 should be used instead. COOKIE one uses T, which may or may not be GMT, depending on the date and local system settings. Maybe we should have proper RFC format too, accompanied with appropriate warning that you should use it with GMT dates (or gmdate())? Well, gmdate() is only part of it; the same constants are also used for the DateTime object (which is preferred over timestamps anyway). The problem lays exactly there because we can't just convert the timezone of an object just for formatting. I wanted to prevent adding just a format letter for the whole format as well (which would partially solve it), but we're almost out of letters. Adding a format letter that forces GMT means we would need to loop over the whole format string twice, making things highly more complicated. It is a tricky one, and let's think about whether we can come up with something useful here. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rfc2616 datetime format?
On Mon, Oct 4, 2010 at 11:29, Pierre Joye pierre@gmail.com wrote: On Mon, Oct 4, 2010 at 10:42 AM, Derick Rethans der...@php.net wrote: On Mon, 4 Oct 2010, Pierre Joye wrote: On Mon, Oct 4, 2010 at 1:27 AM, Stas Malyshev smalys...@sugarcrm.com wrote: It looks like a sub optimal choice to have used string constants instead of integer. However it could be still possible to define new constants as numeric. It is then possible to do whatever needs to be done as post or pre ops for the respective constants. I'm not sure what integers have to do with it? The constants define date formats that are in common use, RFC2616 is one of the commonest on the web and we don't have a constant for it... I mean in ext/date and as a reply to Derick, not your request which is totally valid. A date time object has the timezone information. If the constants were integers, it would be very straightforward to do some operations before calling the formatting functions depending on a given predefined format. It should still be possible to do it by testing the string contents (strncmp), but that's not very clean. Stop talking about something you don't know anything about, please. Those constants are not *one* format letter, they are many. Maybe you could have tried this: echo DateTime::RFC822, \n; Maybe you could read what I wrote instead of replying in such stupid manner, that could lead the discussions in a constructive direction, thanks. Key parts were: 1. using integer makes such features easier to implement (basic good practice/programming 101) 2. use strncmp to compare the format (yes, strncmp supports many characters) Are you proposing that the constants become integers? so, DATE_RFC_1234 will be equal to 1234? And then date(DATE_RFC_1234); will print out formatted string? I am afraid that would break craploads of applications, and become very confusing. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mt_rand deprecated in trunk?
Hi, The comment on this commit: http://svn.php.net/viewvc?view=revisionrevision=303912 suggest getrandmax() and mt_getrandmax() were to be deprecated, but it seems Kalle might have typoed and deprecated mt_rand() instead - is that the case? -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] rfc2616 datetime format?
-Original Message- From: Derick Rethans [mailto:der...@php.net] Sent: 04 October 2010 09:55 To: Stas Malyshev Cc: PHP Internals Subject: Re: [PHP-DEV] rfc2616 datetime format? On Sun, 3 Oct 2010, Stas Malyshev wrote: The reason is that in order to format a DateTime object as GMT, it needs to be converted to GMT... and you can't simply do that with just a constant consisting of a string of format characters. I see what you mean and it makes sense, having constant may imply that you can use it with any date and get proper result... But RFC2616 is the one of the most used formats on the Web - actually, the format that is called COOKIE is not the one that should be used in cookies - RFC2616 should be used instead. COOKIE one uses T, which may or may not be GMT, depending on the date and local system settings. Maybe we should have proper RFC format too, accompanied with appropriate warning that you should use it with GMT dates (or gmdate())? Well, gmdate() is only part of it; the same constants are also used for the DateTime object (which is preferred over timestamps anyway). The problem lays exactly there because we can't just convert the timezone of an object just for formatting. I wanted to prevent adding just a format letter for the whole format as well (which would partially solve it), but we're almost out of letters. Adding a format letter that forces GMT means we would need to loop over the whole format string twice, making things highly more complicated. It is a tricky one, and let's think about whether we can come up with something useful here. cheers, Derick Surely makes better sense to create a function/method for it specifically, rather than adding new formatting letters? Python has something like time.httpdate() Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Comparable interface
On Sun, October 3, 2010 12:34 pm, Gustavo Lopes wrote: * The current behavior for , , etc. is completely useless. It's unpredictable and it doesn't even establish a total order: $a = new stdclass; $a-prop = null; $b = new stdclass; $b-prop2 = null; var_dump($a $b); //false var_dump($a == $b); //false var_dump($b $a); //false E. Which one of these would you expect to be true?... They're sure not equal, right? And what would make $a or $b greater than the other? I mean, *WHY* would you expect one of those to be true, if you do expect one of them to be true? I sure can't find any logical a priori ordering, total, partial, or otherwise. Last time I checked, there was no rule that any set/graph or other mathematical collection had to have a defined ordering, even partial. But it's been ages since I got my Honors Math degree, so maybe they changed the rule while I wasn't looking... :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Comparable interface
On Sun, October 3, 2010 6:18 pm, Stas Malyshev wrote: $a = new stdclass; $a-prop = null; $b = new stdclass; $b-prop2 = null; var_dump($a $b); //false var_dump($a == $b); //false var_dump($b $a); //false That's because there's no total ordering of generic objects that can make sense. Only very specific objects - such as ones representing numeric qualities or having numeric properties - can be ordered, most of objects are unordered. And comparing objects with scalars automagically might bring a lot of surprises as nobody really expects $a == $b and $b == $a to be different now. If you make == not reflexive, I'd be pretty cranky... :-) HOWEVER, here's an idea from left field... If PHP is comparing OBJECTS and cannot discern an ordering, perhaps returning NULL instead of FALSE would make sense. I have NO IDEA if this is do-able, sensible, or reasonable... It just struck me that when PHP doesn't know $a $b should be TRUE/FALSE, returning NULL instead would be a reasonable course of action, from this naive scripter's POV. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rfc2616 datetime format?
On Sun, October 3, 2010 6:27 pm, Stas Malyshev wrote: It looks like a sub optimal choice to have used string constants instead of integer. However it could be still possible to define new constants as numeric. It is then possible to do whatever needs to be done as post or pre ops for the respective constants. I'm not sure what integers have to do with it? The constants define date formats that are in common use, RFC2616 is one of the commonest on the web and we don't have a constant for it... I'm not sure that using 1 for RFC822, 2 for RFC884, ... would have been much better, really... You'd still have to look up the string format, and this GMT one would still be an oddball requiring pre-processing to convert to GMT, as I understand it. Perhaps a whole new pool of constants for gmdate() formatting??? GMT_RFC_2616, for example??? There are probably others in the same boat, yes? Let the record show that I am painfully aware of my ignorance relative to Derick with regards to Date Time matters. :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
