Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67425
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLuqCLhM_5fDkL_7Cdk64oVbwPBMNhFAtixmca3mWWX8VA@mail.gmail.com>
References: <CAF+90c_PPTajBqs636f373DKF=hotrK1ObTojddxx=bxC3g16w@mail.gmail.com>
	<CA+9eiLvnV-i7Zp15oQ1EAzu2u8v_sc_Og8_bqHPBYWH9TyJ9cQ@mail.gmail.com>
	<CAF+90c_KfGWc7U5qA2Ey7FDqscvsRijAF16mqr+aG+561=WT9w@mail.gmail.com>
	<CA+9eiLuiDLYJtwxuUE8_1Het-S-NqaqDC_6gLm8scU253DTidw@mail.gmail.com>
	<CAF+90c9YV4P4MAHe8u2bq3FjVS0LxUtV9mfpni+4j0brvX7yNw@mail.gmail.com>
	<CA+9eiLtF3H=iu87udX8DNm87fWy3oofU1NyZOk7ALeKivRJiTg@mail.gmail.com>
	<CAF+90c9eTPM2ctqj9vGkBxsPSB+ommQnx2bT7e9aZ5VY_N+43A@mail.gmail.com>
	<CA+9eiLuqCLhM_5fDkL_7Cdk64oVbwPBMNhFAtixmca3mWWX8VA@mail.gmail.com>
Date: Tue, 14 May 2013 23:18:09 +0200
Message-ID: <CAF+90c_fS_+euRE6+7HpOci8aUs5yqZWmXEhiK0gu6oyS7PTfg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0149c4688ae95204dcb42ba0
Subject: Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
From: nikita.ppv@gmail.com (Nikita Popov)

--089e0149c4688ae95204dcb42ba0
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 14, 2013 at 7:43 AM, Dmitry Stogov <dmitry@zend.com> wrote:

> Hi Nikita,
>
> Few final notes:
>
> - I wouldn't change zend_object_compare_t into
> zend_object_compare_objects_t. It would be better to name the new function
> as zend_object_compare_zvals_t. (It's just for better backward
> compatibility)
>
Done. Should I also call the handler itself compare_zvals then or can that
stay as just compare?

- Increment and decrement operators in PHP may have different semantic than
> +=1, but I it's probably OK to use ADD/SUB for them.
>
I think we should just introduce this once a use case comes up.


> - In some cases you insert call to zend_object_do_operation into the most
> probable path (e.g. in mod_function). This would cause at lease 2
> additional comparisons and may be conditional jumps. I think it would be
> better to check for most probable operand types first...
>
For $a % $b the most common cases are already handled by fast_mod_function.
mod_function is only directly called when doing $a %= $b. But in any case,
I'm not sure how I could test the more probable cases first, as the next
thing the code does is call convert_to_long. Of course I could copy the
code from fast_mod_function in there, but that doesn't sounds like a good
idea.

I think the only operation that could really be a performance concern is
concat_function, because that's a common operation without a fast_ variant.
But even in that case I could not measure a difference in runtime (taking
averages on 100M concatenations).


> Also it may be better to use a table of callbacks for each overloaded
> operand instead of single one that need to do switch anyway.
>
What would be the benefits? Better performance? Imho using a switch is
handier when implementing the operators, because it requires less
boilerplate code (no need to repeat function signature, variables, shared
code etc).


> Also it may make sense to think about overloading of unary operators to
> provide a solid decision.
>
You mean being able to overload unary + and - directly rather than the
current 0+$a / 0-$a transformation? I can see that this might be useful,
but not sure it's worth it (would have to introduce new opcodes for that).
I'd do the same as with the increment/decrement operators here: Only
implement them once there is a specific use case.

In case you think about user-level operator overloading in the future (that
> may make sense :) it would be better to design them all together.
>
I was thinking about that too, but from the previous discussions on the
topic I figured that there is zero chance for having that in PHP :/

Thanks for the feedback!
Nikita

--089e0149c4688ae95204dcb42ba0--