On Wed, 06 Oct 2010 16:32:40 +0100, Richard Lynch wrote:
On Tue, October 5, 2010 5:44 am, Gustavo Lopes wrote:
On Tue, 05 Oct 2010 04:31:14 +0100, Richard Lynch wrote:
On Sun, October 3, 2010 12:34 pm, Gustavo Lopes wrote:
* The current behavior for >, <, etc. is completely useless. It's
u
On Tue, October 5, 2010 5:44 am, Gustavo Lopes wrote:
> On Tue, 05 Oct 2010 04:31:14 +0100, Richard Lynch
> wrote:
>
>> 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 tot
On Tue, 05 Oct 2010 04:31:14 +0100, Richard Lynch wrote:
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;
$
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 th
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
>
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!
* 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 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 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
For what it's worth, I'm planning to update the RFC later today with
an updated SPL-less patch and the start of a Q&A section similar to
what we've had in the other RFCs. I'll send an e-mail when it's ready.
On 1 October 2010 04:28, Stas Malyshev wrote:
> It is not clear from the RFC, if the engi
Hi!
The RFC is at http://wiki.php.net/rfc/comparable, and the patch at
http://www.adamharvey.name/patches/comparable.diff.txt. Any and all
feedback welcome, particularly since I'm still learning my way around
the innards of the Zend Engine, and it's entirely possible (indeed,
likely) that I've o
On Thu, 30 Sep 2010 16:25:28 +0100, Adam Harvey wrote:
The initial version of the patch actually did just that: it simply
modified zend_std_compare_objects. That's pretty much the cleanest way
you could do it. :)
(...) Additionally, there
are already semantics built into compare_function to ha
On 30 September 2010 23:13, Gustavo Lopes wrote:
> That is, you would only modify zend_std_compare_objects (not
> compare_function!) and add there the additional logic where you'd check if
> the objects had the same class (or perhaps one was of a subclass of the
> other, in which case you'd use th
On Thu, 30 Sep 2010 14:33:05 +0100, Adam Harvey wrote:
I've just written an RFC (with a patch against trunk) to implement a
Comparable interface similar to that in Java — in effect, allowing
object instances to be compared with semantics defined in userspace.
This is admittedly at the lower end
(Omnibus reply, since Johannes's original e-mail hasn't yet dropped
into my ever-so-flaky mail setup. I have read it in full on
news.php.net, though.)
> 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 for
2010/9/30 Johannes Schlüter :
> On Thu, 2010-09-30 at 16:08 +0200, Kalle Sommer Nielsen wrote:
>> I think its a great addition, but I think the interface should be
>> defined within ZE like the other base interfaces that interact
>> directly with the language syntax (like Iterator) and not in SPL.
On Thu, 30 Sep 2010, Johannes Schlüter wrote:
> On Thu, 2010-09-30 at 21:33 +0800, Adam Harvey wrote:
> > All,
> >
> > I've just written an RFC (with a patch against trunk) to implement a
> > Comparable interface similar to that in Java — in effect, allowing
> > object instances to be compared wi
On Thu, 30 Sep 2010 15:26:17 +0100, Johannes Schlüter
wrote:
On Thu, 2010-09-30 at 16:08 +0200, Kalle Sommer Nielsen wrote:
I think its a great addition, but I think the interface should be
defined within ZE like the other base interfaces that interact
directly with the language syntax (like
On Thu, 2010-09-30 at 16:08 +0200, Kalle Sommer Nielsen wrote:
> I think its a great addition, but I think the interface should be
> defined within ZE like the other base interfaces that interact
> directly with the language syntax (like Iterator) and not in SPL.
s/should/has to/
The engine shall
On Thu, 2010-09-30 at 21:33 +0800, Adam Harvey wrote:
> All,
>
> I've just written an RFC (with a patch against trunk) to implement a
> Comparable interface similar to that in Java — in effect, allowing
> object instances to be compared with semantics defined in userspace.
> This is admittedly at
Hi Adam
2010/9/30 Adam Harvey :
> All,
>
> I've just written an RFC (with a patch against trunk) to implement a
> Comparable interface similar to that in Java — in effect, allowing
> object instances to be compared with semantics defined in userspace.
> This is admittedly at the lower end of RFC-w
All,
I've just written an RFC (with a patch against trunk) to implement a
Comparable interface similar to that in Java — in effect, allowing
object instances to be compared with semantics defined in userspace.
This is admittedly at the lower end of RFC-worthy proposals, but it's
a good system, and
26 matches
Mail list logo
