Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21887
Return-Path: <pollita@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 69030 invoked by uid 1010); 16 Feb 2006 22:39:16 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 69015 invoked from network); 16 Feb 2006 22:39:16 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 16 Feb 2006 22:39:16 -0000
X-Host-Fingerprint: 69.12.155.130 69-12-155-130.dsl.static.sonic.net Linux 2.4/2.6
Received: from ([69.12.155.130:2993] helo=pigeon.alphaweb.net)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id F2/00-02786-41FF4F34 for <internals@lists.php.net>; Thu, 16 Feb 2006 17:39:16 -0500
Received: from localhost ([127.0.0.1] helo=peiscg33m)
	by pigeon.alphaweb.net with smtp (Exim 4.10)
	id 1F9qqZ-0002kU-00; Thu, 16 Feb 2006 13:39:31 -0800
Message-ID: <008301c63349$cfa9f8d0$5c8be5a9@ohr.berkeley.edu>
Reply-To: "Sara Golemon" <pollita@php.net>
To: "Zeev Suraski" <zeev@zend.com>,
	"Andi Gutmans" <andi@zend.com>
Cc: <internals@lists.php.net>
References: <002201c6331d$a79473b0$58d01a44@stumpy> <7.0.1.0.2.20060216192615.099c9598@zend.com> <000901c63322$20b5d550$5c8be5a9@ohr.berkeley.edu> <7.0.1.0.2.20060216134358.05a08240@zend.com>
Date: Thu, 16 Feb 2006 14:39:13 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Subject: Re: Minor engine patch to facilitate PECL/operator
From: pollita@php.net ("Sara Golemon")

> <DISCLAIMER>
> I am not a big fan of operator overloading because after years of C++
> development I came to the conclusion that the syntactic sugar it
> provided was not worth the debugging hours lost due to hidden magic
> happening. It actually makes it hard to understand certain code when
> you're just reading it then explicitly calling the methods like in
> Java, something like obj.equals(2).
> </DISCLAIMER>
>
<MYDISCLAIMER>
Believe it or not, I agree with you on the readability problems inherent in
overloading.  I'm not by any measure asking for a blessing or even a whiff
of a consideration of putting this kind of functionality in the language.
It's a decidedly non-PHP feature and one which can stay happily in extension
land where it'll avoid creaping into mainstream projects, while still
existing as a usable tool for those who want it.

Of course, like all good knives, it does have its uses...
</MYDISCLAIMER>

> Anyway, I think this case has some other issues. How would you treat
> 2 < $obj. Wouldn't you want to call $obj->__is_greater(2)? Actually
> my suggestion would be to not make it left associative but to require
> a consistent design. If you have $obj1 < $obj2 then I don't think it
> has to be defined which one gets called or whether __is_smaller or
> __is_greater is called. If either of these are overloaded, it should
> know how to deal with objects that can compare with it (possibly via
> interface, etc..) and with objects that it can't compare to (possibly
> always returning false, etc...).
> So I suggest to create the following behavior:
> $obj < 2 - Calls $obj->__is_smaller(2);
> $obj > 2 - Calls $obj->__is_greater(2); (figures our that 2 isn't
> overloaded so checks $obj)
> $obj1 > $obj2 - Can call either depending on which one implements the
> overloading.
>
I gave this some thought as I was designing the overloading approach. I
didn't go there because I actually wanted to allow asymmetry between the
operands as sometimes communative properties don't apply cleanly.  Most
obviously in the case of sub/div ops, but also in certain other (less
likely) spots like matrix maths. a[1,3] * b[3,1] is certainly different than
b[3,1] * a[1,3].

I'll take a look at applying this to the is_smaller op at least.  I'm not a
master mathematician, but I'm fairly certain that 2 is always greater than
1.(Cue the cue the internals@ response to the contrary)

> We could possibly split that into two opcodes for PHP 6 mainly as a
> "documentation" feature of the source code so less is lost during the
compile.
>
That would certainly address PECL/operator's needs and only costs the engine
in the form of a slightly increased binary (which the extval hack does
anyway).

-Sara