Good evening,
The intdiv RFC is put to the vote, with separate votes for the integer division operator (%%) and intdiv function, the latter as a fallback. I would highly encourage you to read the discussion in the “[RFC] intdiv()” thread and the whole RFC before voting.
The vote is here: https://wiki.php.net/rfc/intdiv#vote
It is opened today (2014-07-30) and ends 2014-08-06.
Thanks!
Andrea Faulds
http://ajf.me/
-1 explanation: I don't think %% is clear enough, the only sensible
syntax choice (//) is unavailable to us, and I think the utility of
having it baked into the language as an operator is pretty minimal
regardless (I coded a lot of Python for scientific research in a
previous job, and I don't think I ever used //, and you'd think that's
the place where you'd use it).
+1 on the function, though — quick searches on Ohloh and Github
suggest that there are a grand total of three open source projects
that implement a global intdiv() function. Seems safe enough.
Adam
Good evening,
The intdiv RFC is put to the vote, with separate votes for the integer division operator (%%) and intdiv function, the latter as a fallback. I would highly encourage you to read the discussion in the “[RFC]
intdiv()” thread and the whole RFC before voting.The vote is here: https://wiki.php.net/rfc/intdiv#vote
It is opened today (2014-07-30) and ends 2014-08-06.
Thanks!
Andrea Faulds
http://ajf.me/
-1 explanation: I don't think %% is clear enough
% returns the 2nd part of the integer division, %% returns the 1st. Surely that makes sense?
I think the utility of
having it baked into the language as an operator is pretty minimal
regardless (I coded a lot of Python for scientific research in a
previous job, and I don't think I ever used //, and you'd think that's
the place where you'd use it).
This actually isn’t something I’d expect to see in science. I think it’s more useful in other fields, like any time you wish to divide into rows (%%) and columns(%).
Andrea Faulds
http://ajf.me/
-1 explanation: I don't think %% is clear enough
% returns the 2nd part of the integer division, %% returns the 1st. Surely that makes sense?
That makes sense in PHP. Probably only in PHP.
-Sara
-1 explanation: I don't think %% is clear enough
% returns the 2nd part of the integer division, %% returns the 1st. Surely that makes sense?
That makes sense in PHP. Probably only in PHP.
Sure. In an ideal world, % would return the quotient and %% the remainder, but alas it is not so.
Andrea Faulds
http://ajf.me/
-1 explanation: I don't think %% is clear enough
% returns the 2nd part of the integer division, %% returns the 1st.
Surely that makes sense?That makes sense in PHP. Probably only in PHP.
Not even in PHP.
--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype
-1 explanation: I don't think %% is clear enough
% returns the 2nd part of the integer division, %% returns the 1st.
Surely that makes sense?That makes sense in PHP. Probably only in PHP.
Not even in PHP.
--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype>
This is why I still think we'd be better off using %/ or /%.
--Kris
They don’t necessarily need to be symbols. Pascal, for example, uses ‘/' for floating-point division, ‘div' for integer division, ‘mod' for modulus, and ‘rem' for remainder. For example:
20 / 8 = 2.5
20 mod 8 = 4
In PHP, we already have precedence for non-symbol in operators like ‘and', ‘or', and ‘instanceof', so it wouldn’t feel too out of place for less commonly used operators.
Just a thought :).
--
Robert E. Williams, Jr.
Senior Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority
https://www.newtekreferrals.com/rewjr
http://www.thesba.com/
Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).
-1 explanation: I don't think %% is clear enough, the only sensible
syntax choice (//) is unavailable to us, and I think the utility of
having it baked into the language as an operator is pretty minimal
regardless (I coded a lot of Python for scientific research in a
previous job, and I don't think I ever used //, and you'd think that's
the place where you'd use it).+1 on the function, though — quick searches on Ohloh and Github
suggest that there are a grand total of three open source projects
that implement a globalintdiv()function. Seems safe enough.Adam
This describes my voting choice exactly. I'm not against the idea of
an operator, but %% is not the right operator choice for me. I could
live with /% but it still doesn't feel quite right. I don't have a
practical implementable suggestion for an alternative, so I guess
we'll just have to live without it.
Of course, this does not preclude us from introducing this in the
future if someone comes up with a better idea :-)
Thanks, Chris
-1 explanation: I don't think %% is clear enough, the only sensible
syntax choice (//) is unavailable to us, and I think the utility of
having it baked into the language as an operator is pretty minimal
regardless (I coded a lot of Python for scientific research in a
previous job, and I don't think I ever used //, and you'd think that's
the place where you'd use it).+1 on the function, though — quick searches on Ohloh and Github
suggest that there are a grand total of three open source projects
that implement a globalintdiv()function. Seems safe enough.Adam
This describes my voting choice exactly. I'm not against the idea of
an operator, but %% is not the right operator choice for me. I could
live with /% but it still doesn't feel quite right. I don't have a
practical implementable suggestion for an alternative, so I guess
we'll just have to live without it.Of course, this does not preclude us from introducing this in the
future if someone comes up with a better idea :-)Thanks, Chris
--
Agreed. I'd very much like to see another RFC that proposes more options
for creating an operator for this. The vote against %% on this RFC should
not be construed-- in my opinion, at least-- as a consensus against having
any kind of operator for intdiv.
--Kris
Agreed. I'd very much like to see another RFC that proposes more options for creating an operator for this. The vote against %% on this RFC should not be construed-- in my opinion, at least-- as a consensus against having any kind of operator for intdiv.
To save hassle, could I not modify the current RFC and hold another vote? I don’t see why we’d need an entirely new RFC.
Andrea Faulds
http://ajf.me/
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Sunday, August 03, 2014 2:52 PM
To: Kris Craig
Cc: Chris Wright; Adam Harvey; PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC]intdiv()Agreed. I'd very much like to see another RFC that proposes more
options
for creating an operator for this. The vote against %% on this RFC
should not
be construed-- in my opinion, at least-- as a consensus against having
any kind
of operator for intdiv.
Based on the discussion on internals@ I'm not sure why it should not be
construed as consensus against any kind of operator for intdiv. Quite the
contrary, those who opposed it (myself included) opposed it on the grounds
that it's not nearly commonly used to be worth a dedicated operator.
Quoting one of those who opposed, "IMHO this is not enough for a new
operator... Especially if this means we have to tolerate something like
%/" (note both the operator being different from the one that ended up
being proposed in the RFC, and the key objection being the necessity of
needing this as an operator in the first place).
To save hassle, could I not modify the current RFC and hold another
vote? I
don't see why we'd need an entirely new RFC.
I think that the best way to save us all hassle is to accept that there's
overwhelming majority against introducing a dedicated operator for this
use case...
I think a revote should be considered only if you come up with a concrete
alternative, and you get a pretty good reason to believe that the results
will be different (e.g. by asking 5-10 people who voted 'no' on the
current RFC and getting a 'yes' from at least some of them). We need to
be respectful of people's time - and generally not assume that something
that was voted upon and rejected, will be accepted after minor mods.
My 2c.
Zeev
Based on the discussion on internals@ I'm not sure why it should not be
construed as consensus against any kind of operator for intdiv. Quite the
contrary, those who opposed it (myself included) opposed it on the grounds
that it's not nearly commonly used to be worth a dedicated operator.
Quoting one of those who opposed, "IMHO this is not enough for a new
operator... Especially if this means we have to tolerate something like
%/" (note both the operator being different from the one that ended up
being proposed in the RFC, and the key objection being the necessity of
needing this as an operator in the first place).To save hassle, could I not modify the current RFC and hold another
vote? I
don't see why we'd need an entirely new RFC.I think that the best way to save us all hassle is to accept that there's
overwhelming majority against introducing a dedicated operator for this
use case...
I think a revote should be considered only if you come up with a concrete
alternative, and you get a pretty good reason to believe that the results
will be different (e.g. by asking 5-10 people who voted 'no' on the
current RFC and getting a 'yes' from at least some of them). We need to
be respectful of people's time - and generally not assume that something
that was voted upon and rejected, will be accepted after minor mods.
Right. While I’d love to hold another vote and get it in, I know it’s not going to happen. Just switching to %/ or something is not going to really change the general consensus against the need for %%. At best, it might mean one more vote in favour but it’s hardly going to swing it.
Unless someone presents me a proposal that will somehow get this a 2/3 majority and actually pleases everyone, it’s not going to be reopened.
--
Andrea Faulds
http://ajf.me/
The intdiv RFC is put to the vote, with separate votes for the integer division operator (%%) and intdiv function, the latter as a fallback. I would highly encourage you to read the discussion in the “[RFC]
intdiv()” thread and the whole RFC before voting.The vote is here: https://wiki.php.net/rfc/intdiv#vote
It is opened today (2014-07-30) and ends 2014-08-06.
Hi!
Voting has ended. The operator vote failed to reach the required 2/3 majority receiving 5 votes in favour and 24 votes against, while the function fallback proposal has been unanimously approved with 28 votes in favour.
I’ll merge the function into master shortly.
Thanks!
--
Andrea Faulds
http://ajf.me/