hi Stas,
On Mon, Oct 4, 2010 at 1:27 AM, Stas Malyshev wrote:
> Hi!
>
>> 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
On Mon, 04 Oct 2010 00:18:36 +0100, Stas Malyshev
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
Hi!
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 t
Hi!
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
Hi!
* 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
That's bec
hi,
On Sun, Oct 3, 2010 at 8:32 PM, Derick Rethans wrote:
> On Fri, 1 Oct 2010, Stas Malyshev wrote:
>
>> Any reason why DateTime doesn't have a constant for RFC2616 (HTTP) date
>> format? RFC1123 and 'r' are _almost_ there but 2616 explicitly states TZ must
>> be "GMT" and 1123 format produces +
On Fri, 1 Oct 2010, Stas Malyshev wrote:
> Any reason why DateTime doesn't have a constant for RFC2616 (HTTP) date
> format? RFC1123 and 'r' are _almost_ there but 2616 explicitly states TZ must
> be "GMT" and 1123 format produces + instead.
The reason is that in order to format a DateTime ob
hi Gustavo,
On Sun, Oct 3, 2010 at 7:34 PM, Gustavo Lopes wrote:
> You raise a fair point -- the motivation to override the comparison operator
> for internal classes is indeed bigger because the state is not in the usual
> places. However:
>
> * The functionality already exists; comparison oper
On Sun, 03 Oct 2010 15:37:41 +0100, Johannes Schlüter
wrote:
On Sun, 2010-10-03 at 15:21 +0100, Gustavo Lopes wrote:
I actually see no reason why we shouldn't expose the compare overload we
already have for internal classes to userspace classes.
For internal classes it is needed, as they
On Sun, 2010-10-03 at 15:21 +0100, Gustavo Lopes wrote:
> On Sun, 03 Oct 2010 15:16:05 +0100, Johannes Schlüter
> wrote:
>
> > On Thu, 2010-09-30 at 22:57 +0800, Adam Harvey wrote:
> >> > On Thu, 30 Sep 2010, Johannes Schlüter wrote:
> >> >> What is this "more interesting stuff to come"?
> >>
>
On Sun, 03 Oct 2010 15:16:05 +0100, Johannes Schlüter
wrote:
On Thu, 2010-09-30 at 22:57 +0800, Adam Harvey wrote:
> On Thu, 30 Sep 2010, Johannes Schlüter wrote:
>> What is this "more interesting stuff to come"?
Nothing that's likely to be ready before the forthcoming release
cycle. I real
On Thu, 2010-09-30 at 22:57 +0800, Adam Harvey wrote:
> > On Thu, 30 Sep 2010, Johannes Schlüter wrote:
> >> What is this "more interesting stuff to come"?
>
> Nothing that's likely to be ready before the forthcoming release
> cycle. I really did just want the RFC writing practice, since I
> haven
On Thu, September 30, 2010 7:20 am, Matthew Weier O'Phinney wrote:
> On 2010-09-29, Stas Malyshev wrote:
> * BC break for existing codebases that have properties and methods of
>the same name. (That's a code smell, anyways, and tools can help
>developers refactor to fix such cases.)
Errr
On Thu, September 30, 2010 8:33 am, Adam Harvey wrote:
> If there's no great resistance to the concept or implementation, I'm
> happy enough to flip this into the voting stage sooner rather than
> later so we can get it out of the way.
If I'm understanding this correctly, you're going to make it W
On Thu, September 30, 2010 9:44 am, Adam Harvey wrote:
> Unrelated to the Comparable RFC, are there any objections to adding a
> function that simply wraps compare_function()? It's depressingly
> common to end up writing a construct like the following in comparison
> callbacks, so I think we might
On Fri, October 1, 2010 8:18 pm, Stas Malyshev wrote:
> Any reason why DateTime doesn't have a constant for RFC2616 (HTTP)
> date
> format? RFC1123 and 'r' are _almost_ there but 2616 explicitly states
> TZ
> must be "GMT" and 1123 format produces + instead.
If you'd find it useful, I don't se
16 matches
Mail list logo
