Good evening,
I am putting the Safe Casting Functions RFC to a vote.
https://wiki.php.net/rfc/safe_cast#vote
Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29).
Since some things might have changed since you last read the RFC, I encourage you to read through it again. If there are any questions which have not yet been covered on the mailing list, feel free to ask them.
Thanks!
Andrea Faulds
http://ajf.me/
Since some things might have changed since you last read the RFC, I encourage you to read through it again. If there are any questions which have not yet been covered on the mailing list, feel free to ask them.
What happens on a 32bit machine?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Since some things might have changed since you last read the RFC, I encourage you to read through it again. If there are any questions which have not yet been covered on the mailing list, feel free to ask them.
What happens on a 32bit machine?
The same as what happens on a 64-bit machine, except the overflow cutoff is obviously much lower.
Andrea Faulds
http://ajf.me/
Since some things might have changed since you last read the RFC, I encourage you to read through it again. If there are any questions which have not yet been covered on the mailing list, feel free to ask them.
- The RFC does not address how this is different from
FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
on the mailing list, but the RFC should say why a tool that already
exists to solve this kind of problem is insufficient, especially when
it is enabled by default. - PHP suffers a lot from function bloat and this RFC provides
multiple functions that do the same thing but differ only in how they
handle errors. A simple validation of "can this be safely cast to an
integer without dataloss?" avoid the issue entirely and would be fewer
functions.
To summarize: I like the idea of having tools that helps us convert
between types in a lossless way, but I don't think this proposal is
what is best for PHP. -1 for me but I hope to see this revisited.
Since some things might have changed since you last read the RFC, I encourage you to read through it again. If there are any questions which have not yet been covered on the mailing list, feel free to ask them.
- The RFC does not address how this is different from
FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
on the mailing list, but the RFC should say why a tool that already
exists to solve this kind of problem is insufficient, especially when
it is enabled by default.
Yes, I suppose that’s a failing of it just now. But to address this:
-
It throws exceptions
-
It is much shorter and more convenient (which is important if we’re to discourage (int), (float) use)
-
to_/try_int() and to_/try_float() don't convert the argument to a string in order to convert
- PHP suffers a lot from function bloat and this RFC provides
multiple functions that do the same thing but differ only in how they
handle errors. A simple validation of "can this be safely cast to an
integer without dataloss?" avoid the issue entirely and would be fewer
functions.
No, no it would not avoid the issue. We had this before with error return values, which are essentially the same as your proposal. People didn’t like only covering one use case. I didn’t like that. Yes, you can write a wrapper function for a validation function that throws an exception. You also could write one for the error return value function. It’s equally objectionable.
Secondly, merely “validating” and not converting means you must then convert after validating. However, the process of validating involves converting it. So you’re doing the same thing twice, essentially, for no conceivable gain.
I’ve said it before, I’ll say it again. There’s nothing which is really any better about just having try_int() return TRUE on success rather than the converted value, and not having to_int().
But I’ve had this argument several times now, so I’m not going to have it again on the mailing list. This will be my last word on that suggestion.
Andrea Faulds
http://ajf.me/
My -1 is pretty much the same as Levi's:
- The RFC does not address how this is different from
FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
on the mailing list, but the RFC should say why a tool that already
exists to solve this kind of problem is insufficient, especially when
it is enabled by default.
I'm also somewhat concerned that these functions are conflating two
concerns (validation and conversion).
- PHP suffers a lot from function bloat and this RFC provides
multiple functions that do the same thing but differ only in how they
handle errors. A simple validation of "can this be safely cast to an
integer without dataloss?" avoid the issue entirely and would be fewer
functions.
+1: the idea of adding two sets of identical functions except for how
they signal errors isn't one I like.
Derick raised a good point elsethread: this is really tied into how we
want to signal errors in PHP 7. If we switch to exceptions, then let's
figure out a plan of attack and switch to exceptions everywhere, not
just in the odd function here and there. If we don't, then the to_*
functions shouldn't be added.
To summarize: I like the idea of having tools that helps us convert
between types in a lossless way, but I don't think this proposal is
what is best for PHP. -1 for me but I hope to see this revisited.
I don't know that I'd ever be a strong +1 on this (adding more type
conversion matrices to PHP doesn't seem like a good idea to me,
whether it's in the language itself or in the standard library, and I
feel like we have the validation part of this already in filter and
ctype), but if we figured out the error handling situation and had
only one set of functions, I could probably grit my teeth and abstain,
at least.
Adam
Not a voter, but I don't really see the usefulness of this in core either.
Sent from my iPhone
My -1 is pretty much the same as Levi's:
- The RFC does not address how this is different from
FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
on the mailing list, but the RFC should say why a tool that already
exists to solve this kind of problem is insufficient, especially when
it is enabled by default.I'm also somewhat concerned that these functions are conflating two
concerns (validation and conversion).
- PHP suffers a lot from function bloat and this RFC provides
multiple functions that do the same thing but differ only in how they
handle errors. A simple validation of "can this be safely cast to an
integer without dataloss?" avoid the issue entirely and would be fewer
functions.+1: the idea of adding two sets of identical functions except for how
they signal errors isn't one I like.Derick raised a good point elsethread: this is really tied into how we
want to signal errors in PHP 7. If we switch to exceptions, then let's
figure out a plan of attack and switch to exceptions everywhere, not
just in the odd function here and there. If we don't, then the to_*
functions shouldn't be added.To summarize: I like the idea of having tools that helps us convert
between types in a lossless way, but I don't think this proposal is
what is best for PHP. -1 for me but I hope to see this revisited.I don't know that I'd ever be a strong +1 on this (adding more type
conversion matrices to PHP doesn't seem like a good idea to me,
whether it's in the language itself or in the standard library, and I
feel like we have the validation part of this already in filter and
ctype), but if we figured out the error handling situation and had
only one set of functions, I could probably grit my teeth and abstain,
at least.Adam
Not a voter, but I don't really see the usefulness of this in core either.
True. This could be on packagist or a php ext, but should not be in
core. Main problem is that it carries too much ambiguity between
validation and coercion while doesn't solve the real problem: strict
typing.
Not a voter, but I don't really see the usefulness of this in core either.
True. This could be on packagist or a php ext, but should not be in
core. Main problem is that it carries too much ambiguity between
validation and coercion while doesn't solve the real problem: strict
typing.
I would argue these are a necessary prerequisite to strict typing.
--
Andrea Faulds
http://ajf.me/
Hi all,
On Fri, Nov 21, 2014 at 10:48 AM, Marcio Almada marcio.web2@gmail.com
wrote:
Not a voter, but I don't really see the usefulness of this in core
either.True. This could be on packagist or a php ext, but should not be in
core. Main problem is that it carries too much ambiguity between
validation and coercion while doesn't solve the real problem: strict
typing.
To be honest, I have mixed feeling for this FRC.
Stricter type check is good. However, it requires runtime cost.
There is an alternative solution that can achieve strict checks without
runtime cost. DbC support does this. It requires user code, but developers
should write code for validation with DbC anyway. With DbC support,
developers
can perform full parameter/return value/state checks.
It may be good to have easy syntax for parameter check in precondition
check block.
function foo($var) {
in {
int: $var;
}
// useful code here
}
Something like this.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
To be honest, I have mixed feeling for this FRC.
Stricter type check is good. However, it requires runtime cost.
One of the area where it is being held up as good practice is filtering
data which is then passed to a database. With best practice on handling
THAT process, the database will be validating data being passed to an
integer or float field as well, and may not follow the same 'new' rules.
There are a number of areas where this is just bloat which has to be
handled differently anyway. For PHP7 the whole picture needs to be
reviewed, not just yet more sticking plasters.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
My -1 is pretty much the same as Levi's:
- The RFC does not address how this is different from
FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
on the mailing list, but the RFC should say why a tool that already
exists to solve this kind of problem is insufficient, especially when
it is enabled by default.
While that was true when Levi said it, the RFC does address this now.
I'm also somewhat concerned that these functions are conflating two
concerns (validation and conversion).
Ideally, usage of these functions should be accompanied by some sort of validation logic if necessary for the application. They aren’t validation functions in themselves, they just prevent certain conversions that don’t make sense. Say someone fails to do proper validation and does this:
$user = User::get((int)$_GET[‘id’]);
With this code, absolutely anything could be passed for “id” in the URL parameter and it’d be converted to a valid integer, transforming garbage into apparently valid values.
On the other hand, say they did this:
$user = User::get(to_int($_GET[‘id’]));
If I pass something that is not a number (like “foobar”), it would throw an exception.
That might not be the best example, I suppose, but it does show where it would hopefully lead to less broken software. A better example might be conversion from an integer to a float within an application. If (int) is used, the data can be horribly mangled beyond recognition (overflow, INF/NAN handling) without so much as a warning. If to_int() is used, then it will throw an exception in this circumstance.
Basically, these functions aren’t meant to be substitutes for validation. Instead, they prevent dangerous conversions. The hope is that people, when needing to convert a value between types, will use these functions rather than the more dangerous explicit casts, and their applications can failsafe if something goes wrong.
- PHP suffers a lot from function bloat and this RFC provides
multiple functions that do the same thing but differ only in how they
handle errors. A simple validation of "can this be safely cast to an
integer without dataloss?" avoid the issue entirely and would be fewer
functions.+1: the idea of adding two sets of identical functions except for how
they signal errors isn't one I like.
The problem is that it’s the least bad of the available options.
Derick raised a good point elsethread: this is really tied into how we
want to signal errors in PHP 7. If we switch to exceptions, then let's
figure out a plan of attack and switch to exceptions everywhere, not
just in the odd function here and there. If we don't, then the to_*
functions shouldn't be added.
This isn’t a switch, though, these are new additions. We already have exceptions in a few places in core, and there’s nothing wrong with new additions using exceptions if and when appropriate. The question is over how to deal with legacy code.
In this specific case, I suppose the other option would have been to throw an E_RECOVERABLE_ERROR. But exceptions can be handled easier, and so I don’t see a particular reason why it shouldn’t throw an exception.
--
Andrea Faulds
http://ajf.me/
- The RFC does not address how this is different from
FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
on the mailing list, but the RFC should say why a tool that already
exists to solve this kind of problem is insufficient, especially when
it is enabled by default.While that was true when Levi said it, the RFC does address this now.
That's fair — I read the RFC again when it first came up for vote, in
my defence, but wanted some time to think about it. I should have
re-read it before actually voting. Sorry about that.
The clunkiness of the filter API is a valid point, although I don't
think unconditionally adding a bunch of unnamespaced functions — which
can be implemented in userspace just fine — is the right way of
dealing with it.
(I've snipped your rationale and example. Thanks for writing it — I
don't necessarily agree with it, but it's a good explanation of your
thinking, and probably something that would have helped the RFC.)
- PHP suffers a lot from function bloat and this RFC provides
multiple functions that do the same thing but differ only in how they
handle errors. A simple validation of "can this be safely cast to an
integer without dataloss?" avoid the issue entirely and would be fewer
functions.+1: the idea of adding two sets of identical functions except for how
they signal errors isn't one I like.The problem is that it’s the least bad of the available options.
I disagree. To my mind, the best option right now (barring the status
quo, which realistically I'd prefer) would be the try_* functions
only. They line up with how ext/standard (and pretty much all of PHP
other than a smattering of OO functions and SPL) signal errors, and
avoid duplication. I don't really fancy explaining the difference
between to_* and try_* in ##php to a new developer.
PHP may be a mishmash of undesigned APIs in places, but that doesn't
mean we should dump fuel on the fire by adding two parallel APIs that
are named obscurely and differ only in how they signal errors.
Derick raised a good point elsethread: this is really tied into how we
want to signal errors in PHP 7. If we switch to exceptions, then let's
figure out a plan of attack and switch to exceptions everywhere, not
just in the odd function here and there. If we don't, then the to_*
functions shouldn't be added.This isn’t a switch, though, these are new additions. We already have exceptions in a few places in core, and there’s nothing wrong with new additions using exceptions if and when appropriate. The question is over how to deal with legacy code.
There's no function in php-src today that throws an exception outside
of an OO context. (Indeed, if you go through the various classes and
methods in php-src, I suspect even in an OO context the majority of
errors are signalled via return values or PHP errors.)
Right now, the standard for appropriateness when adding an exception
is pretty much "is this an error generated in an OO context"? This
clearly isn't.
To be clear: if a way could be designed to do it without shredding BC,
I'd be ecstatic if we deprecated our current error handling system
entirely in favour of exceptions in PHP 7. But that's not the standard
right now, and an unrelated RFC like this isn't the place to make that
decision.
In this specific case, I suppose the other option would have been to throw an E_RECOVERABLE_ERROR. But exceptions can be handled easier, and so I don’t see a particular reason why it shouldn’t throw an exception.
Why would you throw an E_RECOVERABLE_ERROR? The error's been
signalled: the function returned NULL, rather than an
int/float/string.
Adam
The problem is that it’s the least bad of the available options.
I disagree. To my mind, the best option right now (barring the status
quo, which realistically I'd prefer) would be the try_* functions
only. They line up with how ext/standard (and pretty much all of PHP
other than a smattering of OO functions and SPL) signal errors, and
avoid duplication. I don't really fancy explaining the difference
between to_* and try_* in ##php to a new developer.PHP may be a mishmash of undesigned APIs in places, but that doesn't
mean we should dump fuel on the fire by adding two parallel APIs that
are named obscurely and differ only in how they signal errors.There's no function in php-src today that throws an exception outside
of an OO context. (Indeed, if you go through the various classes and
methods in php-src, I suspect even in an OO context the majority of
errors are signalled via return values or PHP errors.)Right now, the standard for appropriateness when adding an exception
is pretty much "is this an error generated in an OO context"? This
clearly isn't.To be clear: if a way could be designed to do it without shredding BC,
I'd be ecstatic if we deprecated our current error handling system
entirely in favour of exceptions in PHP 7. But that's not the standard
right now, and an unrelated RFC like this isn't the place to make that
decision.Why would you throw an E_RECOVERABLE_ERROR? The error's been
signalled: the function returned NULL, rather than an
int/float/string.
try_ serves a different use case to to_. to_ is mostly supposed to be a last line of defence. The only reason it's any safer than an explicit cast is that it throws an error that will halt execution if it goes unhandled. If you have to explicitly check for an error, that means people won't, and the aim of making safer casting as convenient as unsafe casting will not have been achieved. So, the alternative would be an E_RECOVERABLE_ERROR.
try_ exists so you can use the to_ functions in a validation context, where exceptions shouldn't be used for flow control. Of these two sets of functions, if I have to get rid of one, it'd be try_.
Also, a special note: to_/try_string is particularly useful if you want to gracefully handle casting of objects which lack __toString to a string, one of the only cases currently where an explicit cast can fail. There's currently no way to do this aside from checking for the existence of __toString, which isn't necessarily correct as an internal class can allow casting to string without defining that method.
--
Andrea Faulds
http://ajf.me/
Hi Andrea,
Ideally, usage of these functions should be accompanied by some sort of
validation logic if necessary for the application. They aren’t validation
functions in themselves, they just prevent certain conversions that don’t
make sense. Say someone fails to do proper validation and does this:$user = User::get((int)$_GET[‘id’]);With this code, absolutely anything could be passed for “id” in the URL
parameter and it’d be converted to a valid integer, transforming garbage
into apparently valid values.On the other hand, say they did this:
$user = User::get(to_int($_GET[‘id’]));If I pass something that is not a number (like “foobar”), it would throw
an exception.
This is good use case. IMHO.
PHP should provide easy API by default for more secure application.
Parameters sent from client are validated on client with modern web apps.
There are number of cases that validating as int/etc is enough.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Le Wed Nov 19 2014 at 10:57:39 PM, Levi Morrison levim@php.net a écrit :
- PHP suffers a lot from function bloat and this RFC provides
multiple functions that do the same thing but differ only in how they
handle errors. A simple validation of "can this be safely cast to an
integer without dataloss?" avoid the issue entirely and would be fewer
functions.
My "no" is mostly for the reason above, mentioned by Levi and also because
of the use of Exception (previously mentioned by Derick as well).
To improve this RFC, I would:
- use errors/warnings instead of exceptions (unless there is a more global
approach on this aspect for PHP 7). - improve ext/filter to have stricter validation/sanitizing mechanism if
this is missing.
I would personally appreciate a syntax closer to the current casting
mechanism, e.g.:
$int = (=int) "42"; // result: (int) 42
$string = (=string) 42; // result: (string) "42"
$int = (=int) "foobar"; // result: E_ERROR: Can not cast (string)
"foobar" strictly to an int
$int = (~int) "42"; // result: (int) 42
$int = (~int) "foobar"; // result: E_WARNING: Can not cast (string)
"foobar" strictly to an int
Note that I haven't investigate any possible syntax conflict.
My 2 €cents.
Regards,
Patrick
Le Wed Nov 19 2014 at 10:57:39 PM, Levi Morrison levim@php.net a écrit :
- PHP suffers a lot from function bloat and this RFC provides
multiple functions that do the same thing but differ only in how they
handle errors. A simple validation of "can this be safely cast to an
integer without dataloss?" avoid the issue entirely and would be fewer
functions.My "no" is mostly for the reason above, mentioned by Levi and also because of the use of Exception (previously mentioned by Derick as well).
To improve this RFC, I would:
- use errors/warnings instead of exceptions (unless there is a more global approach on this aspect for PHP 7).
Errors in PHP are horrible to handle. There’s absolutely no question of this RFC being revived using errors, at all. If I must, I’ll wait until exceptions are inevitably approved for core in PHP 7. Assuming they actually are. If they aren’t, I might actually quit PHP...
I would personally appreciate a syntax closer to the current casting mechanism, e.g.:
$int = (=int) "42"; // result: (int) 42 $string = (=string) 42; // result: (string) "42" $int = (=int) "foobar"; // result: E_ERROR: Can not cast (string) "foobar" strictly to an int $int = (~int) "42"; // result: (int) 42 $int = (~int) "foobar"; // result: E_WARNING: Can not cast (string) "foobar" strictly to an int
PHP already already has enough bizarre syntaxes, I don’t think it needs even more.
--
Andrea Faulds
http://ajf.me/
Good evening,
I am putting the Safe Casting Functions RFC to a vote.
https://wiki.php.net/rfc/safe_cast#vote
Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29).
Since some things might have changed since you last read the RFC, I
encourage you to read through it again. If there are any questions
which have not yet been covered on the mailing list, feel free to ask
them.
I've voted no because of both ext/filter doing something similar, as
well as this introducing exceptions in ext/standard functionality
without that having been OKed first.
cheers,
Derick
I am putting the Safe Casting Functions RFC to a vote.
https://wiki.php.net/rfc/safe_cast#vote
Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29).
So far only 15 people have voted, that’s very low for this kind of RFC.
I’m tempted to extend voting for another week. It’s not likely to change the outcome, but it would hopefully mean more people vote.
Andrea Faulds
http://ajf.me/
I am putting the Safe Casting Functions RFC to a vote.
https://wiki.php.net/rfc/safe_cast#vote
Voting starts today (2014-11-19) and ends in 10 days’ time
(2014-11-29).So far only 15 people have voted, that’s very low for this kind of RFC.
I’m tempted to extend voting for another week. It’s not likely to
change the outcome, but it would hopefully mean more people vote.
I don't know if it would make a difference here, but I wonder if it would be sensible to add an "abstain" option in votes? That way, someone who has considered an RFC but not formed a strong opinion either way could register that fact. This could even be paired with the notion of a "quorum", i.e. a minimum vote count demonstrating that the outcome of the vote is not the accidental result of "missing" votes, say because several people happened to be on holiday or busy.
Just a thought.
Rowan Collins
[IMSoP]
So far only 15 people have voted, that’s very low for this kind of RFC.
I’m tempted to extend voting for another week. It’s not likely to
change the outcome, but it would hopefully mean more people vote.I don't know if it would make a difference here, but I wonder if it would be sensible to add an "abstain" option in votes? That way, someone who has considered an RFC but not formed a strong opinion either way could register that fact. This could even be paired with the notion of a "quorum", i.e. a minimum vote count demonstrating that the outcome of the vote is not the accidental result of "missing" votes, say because several people happened to be on holiday or busy.
That sounds like a very good idea to me, I, for one, would be happy if this was implemented.
--
Andrea Faulds
http://ajf.me/
So far only 15 people have voted, that’s very low for this kind of RFC.
I’m tempted to extend voting for another week. It’s not likely to
change the outcome, but it would hopefully mean more people vote.
I don't know if it would make a difference here, but I wonder if it would be sensible to add an "abstain" option in votes? That way, someone who has considered an RFC but not formed a strong opinion either way could register that fact. This could even be paired with the notion of a "quorum", i.e. a minimum vote count demonstrating that the outcome of the vote is not the accidental result of "missing" votes, say because several people happened to be on holiday or busy.
That sounds like a very good idea to me, I, for one, would be happy if this was implemented.
A very strong +1 here. It would also give a stronger sense of how many people are actually looking at voting on RFCs in general. I would certainly have felt better casting abstain on several RFCs that’ve recently gone by than with the vote I actually cast (though I stand by my votes in all cases regardless), usually because of lack of strong knowledge of the subject matter.
-- Gwynne Raskind
Hi!
I don't know if it would make a difference here, but I wonder if it
would be sensible to add an "abstain" option in votes? That way,
someone who has considered an RFC but not formed a strong opinion
either way could register that fact. This could even be paired with
You could register that fact by not voting. Why there should be a record
that particular person has no idea what to vote for?
the notion of a "quorum", i.e. a minimum vote count demonstrating
that the outcome of the vote is not the accidental result of
"missing" votes, say because several people happened to be on holiday
or busy.
If there are people too busy to vote but interested in the topic, then
they could ask to extend the vote or postpone if - if there are enough
such people, I do not see why anybody would deny such request. If people
are too busy to even communicate - then I'm not sure what there is to be
done about it. I'm not sure how "quorum" would help - say, there is no
"quorum" - so what we do? Just not vote until... what happens? Hold
indefinitely long votes? Repeat votes until arbitrary threshold is
passed and then argue if that was "accidental" or "gamed" or anything
else? I'm not sure it would be better than holding a straight vote.
Stas Malyshev
smalyshev@gmail.com
Stanislav Malyshev wrote on 27/11/2014 01:03:
Hi!
I don't know if it would make a difference here, but I wonder if it
would be sensible to add an "abstain" option in votes? That way,
someone who has considered an RFC but not formed a strong opinion
either way could register that fact. This could even be paired with
You could register that fact by not voting. Why there should be a record
that particular person has no idea what to vote for?
There's a difference between "has no idea", which implies ignorance, and
"has no strong opinion", which implies ambivalence. Registering an
abstention means "I have read and understood this proposal, but I do not
feel strongly enough to support any of the voting options presented".
Like any vote, that could be followed up by an e-mail explaining the
reasoning behind it.
It might not suit our circumstance, but distinguishing between "didn't
vote" and "registered an abstention" is quite common in the world at
large. Interestingly, the UK parliament doesn't have a mechanism for it,
so MPs will sometimes walk across the House to get themselves listed as
voting both for and against a motion in order to indicate it.
the notion of a "quorum", i.e. a minimum vote count demonstrating
that the outcome of the vote is not the accidental result of
"missing" votes, say because several people happened to be on holiday
or busy.
If there are people too busy to vote but interested in the topic, then
they could ask to extend the vote or postpone if - if there are enough
such people, I do not see why anybody would deny such request. If people
are too busy to even communicate - then I'm not sure what there is to be
done about it. I'm not sure how "quorum" would help - say, there is no
"quorum" - so what we do? Just not vote until... what happens? Hold
indefinitely long votes? Repeat votes until arbitrary threshold is
passed and then argue if that was "accidental" or "gamed" or anything
else? I'm not sure it would be better than holding a straight vote.
Yes, I think a strict numeric quorum requirement is probably overkill
for this situation, I just thought I'd mention it. It works well with a
committee or parliament where turnout is expected to be close to 100%,
because passing on 50% of a 50% turnout is clearly problematic.
But in our case, I'm not even sure what the total number of people who
could vote is, but I suspect there are many who almost never do, making
any hard limit rather arbitrary.
To be clear, I think abstentions still make sense without a quorum
requirement (just not vice versa).
Regards,
Rowan Collins
[IMSoP]
I am putting the Safe Casting Functions RFC to a vote.
https://wiki.php.net/rfc/safe_cast#vote
Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29).
Hi,
Judging from the discussions we've had with other members of AFUP, I'm
guessing we'd kind of be +0.5 to this.
Having a proper definition of what is a valid int/float/string could
prove useful, especially in a context of stronger typing (like scalar
type-hints, which is one case this definition would be the most helpful).
This definition would have to be considered as some kind of an
official one, though -- and not just be used for a few functions.
Staying within the context of this RFC, we'd probably prefer the try_*()
version of those functions, which would be useful for validations --
even if throwing exceptions from regular non-OO functions is not quite
(for now?) the PHP way.
Not a full +1 though, mainly because these functions only feel like
half-a-step towards stronger typing.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
Good evening,
I am putting the Safe Casting Functions RFC to a vote.
https://wiki.php.net/rfc/safe_cast#vote
Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29).
Good evening again,
The final vote total comes to 5:16 Yes:No, so by a 3/4 majority the RFC is rejected and voting is closed.
I might revive this at some point in future with modifications, but I’ll wait to see what happens with Nikita’s Exceptions in the Engine for PHP 7 RFC, before I do anything with that.
Thanks!
--
Andrea Faulds
http://ajf.me/