Hi internals,
I've opened up the pow-operator RFC for voting.
https://wiki.php.net/rfc/pow-operator#proposed_voting_choices
Contrary to previous emails, the vote will be an all-or-nothing "Yes / No".
The proposed voting cut off date is 31st of Dec.
--
Tjerk
Hi,
As it currently stands the votes are quite polarized, so let me address the
most likely issue: associativity.
The reason I chose for having it right associative is based on mathematical
notation, not a personal preference. I do personally think that the
distinction isn't going to matter in 99% of the cases and nobody in their
right mind would write $x ** $y ** $z in production code without testing
either. And lastly, Matlab is wrong, there's only one right associativity :)
If this proposal doesn't make it, I have no intentions on restarting it in
the future to address above concerns.
That said, if there are other reasons for voting 'no' besides
associativity, feel free to shoot me an email or discuss it on the list.
On Wed, Dec 18, 2013 at 4:31 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
Hi internals,
I've opened up the pow-operator RFC for voting.
https://wiki.php.net/rfc/pow-operator#proposed_voting_choices
Contrary to previous emails, the vote will be an all-or-nothing "Yes / No".
The proposed voting cut off date is 31st of Dec.
--
Tjerk
--
Tjerk
That said, if there are other reasons for voting 'no' besides
associativity, feel free to shoot me an email or discuss it on the list.
What did it for me was the lower precedence for the unary minus. I don't
want to have another language that thinks a negative number squared is a
negative number. I understand and respect your reasoning as outlined in
the RFC, but this is a deal-breaker for me.
--Kris
Hi Kris,
That said, if there are other reasons for voting 'no' besides
associativity, feel free to shoot me an email or discuss it on the list.What did it for me was the lower precedence for the unary minus. I don't
want to have another language that thinks a negative number squared is a
negative number. I understand and respect your reasoning as outlined in
the RFC, but this is a deal-breaker for me.
I've had a short discussion with Anthony about this and he convinced me
that I was indeed wrong about my "unary minus" reasoning; therefore I have
updated the RFC to reflect that. So:
echo -3 ** 2; // 9
echo 1 - 3 ** 2; // -8
The unary minus is now at the same level as [, the array dereferencing
operator.
--Kris
--
Tjerk
On Wed, Dec 18, 2013 at 6:04 PM, Tjerk Meesters
tjerk.meesters@gmail.com wrote:
Hi Kris,
That said, if there are other reasons for voting 'no' besides
associativity, feel free to shoot me an email or discuss it on the list.What did it for me was the lower precedence for the unary minus. I don't
want to have another language that thinks a negative number squared is a
negative number. I understand and respect your reasoning as outlined in
the RFC, but this is a deal-breaker for me.I've had a short discussion with Anthony about this and he convinced me
that I was indeed wrong about my "unary minus" reasoning; therefore I have
updated the RFC to reflect that. So:
I'm a little bit confused.
Are you modifying the poll, and the rfc itself, in the middle of a vote?
-Hannes
Hi Hannes,
On Thu, Dec 19, 2013 at 10:08 AM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:
On Wed, Dec 18, 2013 at 6:04 PM, Tjerk Meesters
tjerk.meesters@gmail.com wrote:Hi Kris,
On Thu, Dec 19, 2013 at 8:35 AM, Kris Craig kris.craig@gmail.com
wrote:That said, if there are other reasons for voting 'no' besides
associativity, feel free to shoot me an email or discuss it on the
list.What did it for me was the lower precedence for the unary minus. I
don't
want to have another language that thinks a negative number squared is a
negative number. I understand and respect your reasoning as outlined in
the RFC, but this is a deal-breaker for me.I've had a short discussion with Anthony about this and he convinced me
that I was indeed wrong about my "unary minus" reasoning; therefore I
have
updated the RFC to reflect that. So:I'm a little bit confused.
Are you modifying the poll, and the rfc itself, in the middle of a vote?
You're right. I've made a faux pas, I shouldn't have done that.
Sorry Kris, the change is reverted; in fact, the following documents back
up my original implementation choice:
http://math.stackexchange.com/questions/491933/exponent-rules-with-negative-numbers
http://math.stackexchange.com/questions/68833/what-does-22-evaluate-to/68834#68834
If the conceptual design of php is that unary operators must bind stronger
than any binary operator, we would have to restart the vote but I'm hoping
that won't be necessary.
I shouldn't make decisions before coffee. Apologies for the confusion!
-Hannes
--
Tjerk
On Wed, Dec 18, 2013 at 10:17 PM, Tjerk Meesters
tjerk.meesters@gmail.comwrote:
Hi Hannes,
On Thu, Dec 19, 2013 at 10:08 AM, Hannes Magnusson <
hannes.magnusson@gmail.com> wrote:On Wed, Dec 18, 2013 at 6:04 PM, Tjerk Meesters
tjerk.meesters@gmail.com wrote:Hi Kris,
On Thu, Dec 19, 2013 at 8:35 AM, Kris Craig kris.craig@gmail.com
wrote:That said, if there are other reasons for voting 'no' besides
associativity, feel free to shoot me an email or discuss it on the
list.What did it for me was the lower precedence for the unary minus. I
don't
want to have another language that thinks a negative number squared
is a
negative number. I understand and respect your reasoning as outlined
in
the RFC, but this is a deal-breaker for me.I've had a short discussion with Anthony about this and he convinced me
that I was indeed wrong about my "unary minus" reasoning; therefore I
have
updated the RFC to reflect that. So:I'm a little bit confused.
Are you modifying the poll, and the rfc itself, in the middle of a vote?
You're right. I've made a faux pas, I shouldn't have done that.
Sorry Kris, the change is reverted; in fact, the following documents back
up my original implementation choice:http://math.stackexchange.com/questions/491933/exponent-rules-with-negative-numbers
http://math.stackexchange.com/questions/68833/what-does-22-evaluate-to/68834#68834
If the conceptual design of php is that unary operators must bind stronger
than any binary operator, we would have to restart the vote but I'm hoping
that won't be necessary.I shouldn't make decisions before coffee. Apologies for the confusion!
-Hannes
--
Tjerk
I honestly do not think that the preference of associativity should
out-weigh the benefits of this RFC (having an exponentiation operator).
As covered in the discussion portion and the RFC, the matter of
associativity is clearly preferential and varies form one language to
another, with the majority of languages (reviewed) leaning towards
right-associative exponentiation operators due to the usefulness of
power-tower. Now, with all this said, that doesn't change the fact that
forcing operator precedence is always possible in every language and no
good developer would rather be sorry than safe. So why associativity should
be a strong basis for accepting or rejecting this RFC is beyond me.
Personally, I would rather have the operator in the language, regardless of
the associativity, than not have it at all.
On Thu, Dec 19, 2013 at 4:17 AM, Tjerk Meesters
tjerk.meesters@gmail.com wrote:
I shouldn't make decisions before coffee. Apologies for the confusion!
Right :)
Please restart the poll then and extend the end date.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Thu, Dec 19, 2013 at 4:17 AM, Tjerk Meesters
tjerk.meesters@gmail.com wrote:I shouldn't make decisions before coffee. Apologies for the confusion!
Right :)
Please restart the poll then and extend the end date.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Agreed. I like(d) the change but they're right it shouldn't happen in the
middle of a vote.
How about modifying the RFC so that there's a voting option for each method
(three options total)? We've done something similar on previous votes
without any problems. Then you could wipe all the votes clean and start
the process over as the others suggested. I think that'd be a reasonable
approach.
--Kris
That said, if there are other reasons for voting 'no' besides
associativity, feel free to shoot me an email or discuss it on the list.What did it for me was the lower precedence for the unary minus. I don't
want to have another language that thinks a negative number squared is a
negative number. I understand and respect your reasoning as outlined in
the RFC, but this is a deal-breaker for me.I've had a short discussion with Anthony about this and he convinced me
that I was indeed wrong about my "unary minus" reasoning; therefore I have
updated the RFC to reflect that. So:echo -3 ** 2; // 9
echo 1 - 3 ** 2; // -8The unary minus is now at the same level as
[, the array dereferencing
operator.
We should follow the mathematic precedence rules; -3 ** 2 should be -9.
Note that "-3^2" as input to Mathematica, Matlab and Google search engine
all gave -9 as the answer, as mathematically expected.
That said, if there are other reasons for voting 'no' besides
associativity, feel free to shoot me an email or discuss it on the list.What did it for me was the lower precedence for the unary minus. I don't
want to have another language that thinks a negative number squared is a
negative number. I understand and respect your reasoning as outlined in
the RFC, but this is a deal-breaker for me.I've had a short discussion with Anthony about this and he convinced me
that I was indeed wrong about my "unary minus" reasoning; therefore I have
updated the RFC to reflect that. So:echo -3 ** 2; // 9
echo 1 - 3 ** 2; // -8The unary minus is now at the same level as
[, the array dereferencing
operator.We should follow the mathematic precedence rules; -3 ** 2 should be -9.
Note that "-3^2" as input to Mathematica, Matlab and Google search engine
all gave -9 as the answer, as mathematically expected.
It would be quite strange if we treated "0 - 3 ^ 2" and "- 3 ^ 2"
differently. They should be identical!
--
Andrea Faulds
http://ajf.me/
Sorry I'm late (possibly too late?) to this, but:
- if
pow()is turning from a function into a construct, can it still be used for callbacks? I don't see a mention of that part in the RFC. - if
pow()drops the overhead of a function call, does-3 ** 2really gain us anything overpow(-3, 2)? The latter is /far/ less ambiguous IMO.
S
Sorry I'm late (possibly too late?) to this, but:
- if
pow()is turning from a function into a construct, can it still be used for callbacks? I don't see a mention of that part in the RFC.- if
pow()drops the overhead of a function call, does-3 ** 2really gain us anything overpow(-3, 2)? The latter is /far/ less ambiguous IMO.
In answer to your second point: Yes. Math is much easier when you don't
have to write everything in Polish notation. I don't want to do
pow(add(2, div(7, 3)), 8), I want to do (2 + 7/3) ** 8.
--
Andrea Faulds
http://ajf.me/
Hi Sean,
Sorry I'm late (possibly too late?) to this, but:
- if
pow()is turning from a function into a construct, can it still be
used for callbacks? I don't see a mention of that part in the RFC.
It's implied in this section:
No changes to existing code, safe for one:
var_dump(pow([], 2)); // int(0) instead of float(0)
Perhaps it could be made more obvious, but yes, the original function
remains there to serve exactly the purpose of callbacks; its innards have
been replaced by calling the PHP_SAPI pow_function(), though.
- if
pow()drops the overhead of a function call, does-3 ** 2really
gain us anything overpow(-3, 2)? The latter is /far/ less ambiguous IMO.
Yes, it allows you to write an expression more naturally; regarding the
second part of your question, (-3) ** 2 is also far less ambiguous :)
S
--
Tjerk
Hi Sean,
Sorry I'm late (possibly too late?) to this, but:
- if
pow()is turning from a function into a construct, can it still be
used for callbacks? I don't see a mention of that part in the RFC.It's implied in this section:
No changes to existing code, safe for one:
var_dump(pow([], 2)); // int(0) instead of float(0)
Perhaps it could be made more obvious, but yes, the original function
remains there to serve exactly the purpose of callbacks; its innards have
been replaced by calling thePHP_SAPIpow_function(), though.
Can you make the RFC clearer?
(In general, RFCs are not good at accepting feedback from mail list discussions.)
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html