Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Hi Anthony, I have been interested in this proposal for a while now. I'm not on internals, but I have a question about your proposal. 1. declare(strict_types=1) (if used) is required to be the first instruction in the file only. No other usages allowed. How would this work with namespaces? declare(strict_types=1) namespace Foo; namespace Bar; declare(strict_types=1) strict namespace Baz; Really good proposal though. Really hope it passes vote and we finally get scalar type hints in PHP. Cheers, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Chris, I'll edit in the proposal, but you can check the tests in the mean time: https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_002.phpt https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_004.phpt https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_005.phpt So it needs to come before the namespace declaration (in fact, it currently needs to be the first declaration in the file). Though I am about to implement the block syntax, and that may alter things slightly (though declare will be required to be outside the namespace). Anthony On Fri, Feb 20, 2015 at 6:07 AM, Chris Harvey ch...@chrisnharvey.com wrote: Hi Anthony, I have been interested in this proposal for a while now. I'm not on internals, but I have a question about your proposal. 1. declare(strict_types=1) (if used) is required to be the first instruction in the file only. No other usages allowed. How would this work with namespaces? declare(strict_types=1) namespace Foo; namespace Bar; declare(strict_types=1) strict namespace Baz; Really good proposal though. Really hope it passes vote and we finally get scalar type hints in PHP. Cheers, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On 19/02/15 04:44, Dennis Birkholz wrote: I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! DO NOT USE OTHER CHANNELS! With the large number of secondary channels the only place that suggestions like that should be made is here and as far as I have seen both ideas are still 'active'? But I do find it crass that there is now a different document with no reference to the v4 history! What does need unravelling is just which bits go with which discussion across all of the areas. I'm still looking at how any of this applies to the values in the arrays I'm passing around and just getting more and more confused. What I think I want is a set of functions to replace all this casting mess. Rather than is_bool ... as_bool similarly as_int64 rather than getting an automatic float. I want to ask to look at a variable in the array as the type I need for the job in hand now you may say that is 'casting' but you are not providing me with the casts *I* and many other database users need. I can see the 'advantage' of optimizing code via this strict stuff that some people want, but I don't see that has any place in a 'run only' version of PHP. If you want to compile the code then use a port of PHP that is compiled. Leave those of use who prefer the more dynamic system which may well have to deal differently with a scalar variable depending on what is returned at runtime. On the minus side of this drive to 'optimize' the code is the potential for completely different code on 32bit systems over 64bit ones. If the number is below 32bit then a completely different set of code gets used using only 32bit instructions. This may well be good for speed, but can introduce cross platform differences that may be difficult to debug. We currently live with those problems already with the int-float agro on 64bit numbers. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
De : Lester Caine [mailto:les...@lsces.co.uk] On 19/02/15 04:44, Dennis Birkholz wrote: I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! DO NOT USE OTHER CHANNELS! Agreed. And the RFC was not abandoned at all. I and others have been working almost continuously on a 'compromise' single-mode approach during the last 3 days (and nights), as activity on the list shows with no doubt. So, pretending the RFC to be 'abandoned' is just a way to discard a disagreed work. As long as she does not officially gives up (posting to the list), I'll keep considering Sara still has the lead on scalar type hinting. If she officially gives up, I'll immediately propose to take it over and, if we are several to want it, we'll discuss. That's the rule and I encourage list members to explicitly show their support to the formal process we all agreed upon. For the rest, Lester summarized quite well my view about designing PHP for static analysis, instead of static analysis for PHP ;) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Dennis,
Will you consider to let the people vote on how to enable strict mode
like discussed in the v0.4 discussion? Like this here from the Reviving
scalar type hints thread?
I believe that RFCs should be opinionated. I dislike the recent trend
around having a lot of voting options as it only complicates things
for the voter.
For this reason I have chosen what I think is technically the best
option and went from there. I am definitely open to changing that, but
it would need to be based on technical reasons and not just popular
preference. Heck, in a recent public poll, over 20% of respondents
voted for it being an ini setting.
I touched on the reasons in the RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5#why_not_use_use_strict_instead_of_declare
But let me go through them one-by-one:
Am 17.02.2015 um 00:58 schrieb Sara Golemon: Straw poll:
1) ?php strict;
This is new syntax, which is potentially ambiguous around what
strictness is being applied. It limits future compatibility.
Additionally, it's potentially ambiguous if a file starts with ?=
strict; 4; ?. Is that setting strict mode for a file and outputting
4? Or is it outputting the constant strict? Sure, this could be
solved with a rule that it could only follow ?php, but that starts
to get arbitrary and potentially confusing, given the other ways to
open PHP tags.
2) ?php-strict
STRONG -1, as it leaves potential for code disclosure if run on a
earlier version of PHP.
3) use strict; (psuedo-namespace)
Re-using namespaces to effect runtime is weird. Not to mention what's
the expected behavior of block mode:
?php
namespace Foo {
use strict;
}
namespace {
bar();
}
?
is bar() called in strict mode? Or in non-strict mode?
4) ?php // strict (I don't actually like HHVM's style, but if you do...)
Comments should not affect runtime behavior. HHVM uses it as they need
to affect behavior while remaining compatible with PHP. We do not have
that problem.
5) declare(strict=true); (As a top-level declare only)
6) declare(strict=true); (exactly as in v0.3 -- maybe you liked it)
Which had a number of people against it, with arguments about the odd
behavior of declare in blocks, etc.
7) your write-in vote here
The only other one I've seen that *might* make sense is using a strict
qualifier on the namespace declaration:
strict namespace Foo {
}
IMO this has the same issues as use strict above. However, it also
seems to imply that the namespace is strict, where it's only the
declarations in the file that are.
I'm 100% open to technical arguments and justification to switch to
another syntax. I don't believe that it should be a poll though.
That's why I made a decision and backed it up. If anyone has logical
arguments or disagrees, let's discuss it. That way the proposal can be
improved through collaboration rather than just a blind vote.
Thanks for the feedback!!!
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Francois and Lester (and all), Please keep this thread on-topic. It should be for technical discussions around this RFC only. If you have something non-technical to discuss, please start a new topic. Thanks Anthony On Thu, Feb 19, 2015 at 6:58 AM, François Laupretre franc...@php.net wrote: De : Lester Caine [mailto:les...@lsces.co.uk] On 19/02/15 04:44, Dennis Birkholz wrote: I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! DO NOT USE OTHER CHANNELS! Agreed. And the RFC was not abandoned at all. I and others have been working almost continuously on a 'compromise' single-mode approach during the last 3 days (and nights), as activity on the list shows with no doubt. So, pretending the RFC to be 'abandoned' is just a way to discard a disagreed work. As long as she does not officially gives up (posting to the list), I'll keep considering Sara still has the lead on scalar type hinting. If she officially gives up, I'll immediately propose to take it over and, if we are several to want it, we'll discuss. That's the rule and I encourage list members to explicitly show their support to the formal process we all agreed upon. For the rest, Lester summarized quite well my view about designing PHP for static analysis, instead of static analysis for PHP ;) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Hello Anthony, Am 19.02.2015 um 14:01 schrieb Anthony Ferrara: I believe that RFCs should be opinionated. I dislike the recent trend around having a lot of voting options as it only complicates things for the voter. I just thought giving a vote on how to enable strict mode would enable a few more people to actually vote yes. I myself can not vote but I really hope we get scalar type hints in what kind soever into PHP 7. So keep on and thank you for taking over. Greets Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On Thu, Feb 19, 2015 at 12:50 AM, Anthony Ferrara ircmax...@gmail.com wrote: Leigh, Internal Functions Like ceil() Return Unexpected Types My opinion is that functions should return sane types for their intended purpose, and functions that do not should be fixed. I agree 100%. I just think that's outside the scope of this proposal. Static Analysis Is Possible With Weak Declarations The advocacy of allowing `accepts_float(returns_int());` doesn't help the cause of static analysers in strict mode. Java does exactly this and is statically analyzable. So...? PHP is not a language for static analyzes or verification!!! Strict typing shouldn't be done on language level. it may be implemented as a custom verification extension, but please, don't break the language itself. Thanks. Dmitry. Still no mention of a way to enable strict by default. So lets try some different rationale. If I personally want to develop in strict mode, I can do that with this proposal, I can add a declare to the top of every file and be as strict as I like. However not everyone else is going to want to use my code in strict mode, so they will have to go and remove some/all of those strict declarations. (Lets take callbacks being evaluated in the context they are called rather than the one they are created in). I would like a way of enabling strict by default, immutable to scripts so that users cannot be forced into this mode, and lets the radicals and the weaklings* play together in harmony. I missed that discussion point, so I've just added it: https://wiki.php.net/rfc/scalar_type_hints_v5#why_not_add_an_ini_setting_for_default_mode For the rest of the RFC, I either agree with or have no strong opinions about the points raised. Thanks for the input :-) Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Robert,
you wrote: aliases are removed (integer and boolean)
what about the aliases real and double?
They were never part of Andrea's proposal. So they were never accepted anyway.
You wrote: behaviour of weak type checks: float - int *Only non-NaN floats
between PHP_INT_MIN and PHP_INT_MAX accepted. (New in PHP 7, see the ZPP
Failure on Overflow RFC)
What about INF? Can INF be passed or not and if so, how is it converted?
Please see the other RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow
Namely: The special floating-point values INF and -INF fail the check
like any other number that is too large.
Personally I would be stricter and disallow int-bool, float-bool,
string-bool as well as bool - int, bool - float and bool - string (at
least for this RFC)
Why?
1. I already mentioned the common if(strpos(..)){} case but is something
which none of the RFC addressed so far and probably goes too far (you wrote
In addition to userland functions, the strict type checking mode also
affects extension and built-in PHP functions: but control structures are not
affected, right?)
This only affects function calls. Not control structures.
2. It supports an inconsistency in PHP which we should try to get away with
rather than promoting it. Following an example:
function foo(string $x){
var_dump($x);
bar($x);
}
function bar(bool $x){
var_dump($x);
baz($x);
}
function baz(string $x){
var_dump($x);}
foo(0);
and the output would be:
string(1) 0
bool(false)
string(0)
Sure, removing the implicit conversions from and to bool do not pretend that
the same would happen if one uses manual conversions instead. Yet, IMO we
should forbid the implicit conversion from and to bool now and add it later
on with consistent conversion rules. This way we have more time to think
about a clean solution and adding implicit conversion from and to bool should
also not be a BC break in 7.1
Simple: don't use weak mode. This proposal does not invent the weak
mode rules, it simply exposes them from ZPP (how it's implemented in
all internal functions) to userland hints.
So any change there would be outside of scope for this proposal and
should be made as another proposal. I will add this to the discussion
points section.
Another example:
function foo(int $x){
var_dump($x);
bar($x);
}
function bar(string $x){
var_dump($x);
}
foo(false);
bar(false);
and output:
int(0)
string(1) 0
string(0)
I think you get the inconsistency I am writing about.
About widening. It is not clear from the RFC if widening is only applied for
int - float or also for bool - int, bool - float respectively.
It's explicitly stated: This means that parameters that declare float
can also accept int.
I will clarify this as well.
Thanks!
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On 18 February 2015 at 21:50, Anthony Ferrara ircmax...@gmail.com wrote: Static Analysis Is Possible With Weak Declarations The advocacy of allowing `accepts_float(returns_int());` doesn't help the cause of static analysers in strict mode. Java does exactly this and is statically analyzable. So...? As discussed elsewhere. You're absolutely right, it is up to the analyser to throw a warning on this because it is a type-based conversion rather than value based one. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Hi, On Wed, Feb 18, 2015 at 11:23 PM, Leigh lei...@gmail.com wrote: I would like a way of enabling strict by default, immutable to scripts so that users cannot be forced into this mode, and lets the radicals and the weaklings* play together in harmony. For the rest of the RFC, I either agree with or have no strong opinions about the points raised. *it's a joke you guys. I am still bipolar and I still want both to co-exist with no switches and modes. :) No joke. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Leigh, Internal Functions Like ceil() Return Unexpected Types My opinion is that functions should return sane types for their intended purpose, and functions that do not should be fixed. I agree 100%. I just think that's outside the scope of this proposal. Static Analysis Is Possible With Weak Declarations The advocacy of allowing `accepts_float(returns_int());` doesn't help the cause of static analysers in strict mode. Java does exactly this and is statically analyzable. So...? Still no mention of a way to enable strict by default. So lets try some different rationale. If I personally want to develop in strict mode, I can do that with this proposal, I can add a declare to the top of every file and be as strict as I like. However not everyone else is going to want to use my code in strict mode, so they will have to go and remove some/all of those strict declarations. (Lets take callbacks being evaluated in the context they are called rather than the one they are created in). I would like a way of enabling strict by default, immutable to scripts so that users cannot be forced into this mode, and lets the radicals and the weaklings* play together in harmony. I missed that discussion point, so I've just added it: https://wiki.php.net/rfc/scalar_type_hints_v5#why_not_add_an_ini_setting_for_default_mode For the rest of the RFC, I either agree with or have no strong opinions about the points raised. Thanks for the input :-) Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On 18 February 2015 at 20:44, Anthony Ferrara ircmax...@gmail.com wrote:
Dear Internals,
Since the resignation of Andrea, the mixed-mode type hint (called
declaration in the proposal) proposal has been left abandoned.
Considering that the ending votes were 67/34 (66.3%) with several
no-votes being only due to reasonably minor issues with the proposal,
I would like to re-propose her RFC with three minor modifications:
1. declare(strict_types=1) (if used) is required to be the first
instruction in the file only. No other usages allowed.
2. declare(strict_types=1) {} (block mode) is specifically disallowed.
3. int typed variables can resolve a parameter type of float So
calling requiresAFloat(10) will work even in strict mode.
As this topic has and is being discussed to death, I have put a very
large discussion points section:
https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
I would kindly ask, before replying that you check to see if your
question is answered in that list.
General comments from me, as a radical strictist. No need to reply and
tell me I'm wrong, these are my opinions.
Internal Functions Like ceil() Return Unexpected Types
My opinion is that functions should return sane types for their
intended purpose, and functions that do not should be fixed.
Integers Should Be Accepted For Strict float Arguments
Int-Float Exception Makes Strict Mode Flawed
My opinion is that strict should mean strict.
Static Analysis Is Possible With Weak Declarations
The advocacy of allowing `accepts_float(returns_int());` doesn't help
the cause of static analysers in strict mode.
Why Not Add Support For Null?
I agree a null type is pointless, however I would like to raise the
discussion point of existing hinted optional parameters being allowed
a default of null. i.e. fn(Obj $o = null) {}
Do you think this is acceptable for any other types? I can only think
of it being useful if resource and a generic object type are added.
but others may disagree. (Ideally the resource type will go away over
time and will be replaced with objects like GMP anyway :))
Still no mention of a way to enable strict by default. So lets try
some different rationale. If I personally want to develop in strict
mode, I can do that with this proposal, I can add a declare to the top
of every file and be as strict as I like. However not everyone else is
going to want to use my code in strict mode, so they will have to go
and remove some/all of those strict declarations. (Lets take callbacks
being evaluated in the context they are called rather than the one
they are created in). I would like a way of enabling strict by
default, immutable to scripts so that users cannot be forced into this
mode, and lets the radicals and the weaklings* play together in
harmony.
For the rest of the RFC, I either agree with or have no strong
opinions about the points raised.
*it's a joke you guys.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Albert, On Wed, Feb 18, 2015 at 5:21 PM, Albert Casademont Filella albertcasadem...@gmail.com wrote: Hi Anthony! Thanks for bringing this up again. I am asking you the same I asked Andrea 2 weeks ago on Twitter: make it a triple option vote please. She didn't want to do it, hope you do! This way you eliminate the neverending discussion about weak vs strict, let the votes decide and see who really prefers weak type hinting only and who prefers the stricter way, both camps will have an option to vote. So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes combined need 2/3 of the votes. Then a simple majority of 50%+1 between the different Yes votes is needed. Thanks for the feedback. I have added it to the discussion points: https://wiki.php.net/rfc/scalar_type_hints_v5#this_proposal_should_have_multiple_vote_options The text: This is not a two-part proposal. The proposal is of a unified system that was designed to work together. As such, neither part (weak-only or strict-only) is designed to stand on its own without the other part. Therefore, it only makes sense to vote on this proposal as a whole. Therefore, the voting options this RFC will present will be: Yes and No. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Hi Anthony!
Thanks for bringing this up again. I am asking you the same I asked Andrea
2 weeks ago on Twitter: make it a triple option vote please. She didn't
want to do it, hope you do! This way you eliminate the neverending
discussion about weak vs strict, let the votes decide and see who really
prefers weak type hinting only and who prefers the stricter way, both camps
will have an option to vote.
So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes
combined need 2/3 of the votes. Then a simple majority of 50%+1 between the
different Yes votes is needed.
Thanks!
Albert
On Wed, Feb 18, 2015 at 9:44 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Dear Internals,
Since the resignation of Andrea, the mixed-mode type hint (called
declaration in the proposal) proposal has been left abandoned.
Considering that the ending votes were 67/34 (66.3%) with several
no-votes being only due to reasonably minor issues with the proposal,
I would like to re-propose her RFC with three minor modifications:
1. declare(strict_types=1) (if used) is required to be the first
instruction in the file only. No other usages allowed.
2. declare(strict_types=1) {} (block mode) is specifically disallowed.
3. int typed variables can resolve a parameter type of float So
calling requiresAFloat(10) will work even in strict mode.
As this topic has and is being discussed to death, I have put a very
large discussion points section:
https://wiki.php.net/rfc/scalar_type_hints_v5#discussion_points
I would kindly ask, before replying that you check to see if your
question is answered in that list.
If it is not, please follow up here and I will update the RFC.
If your question is listed and you feel that it wasn't given proper
due, please let's discuss that.
https://wiki.php.net/rfc/scalar_type_hints_v5
Considering this proposal is a minor tweak on an already-discussed and
voted-on proposal, I plan on bringing this RFC to vote 1 week from
today (on February 25th, 2015).
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Am 18.02.2015 um 21:44 schrieb Anthony Ferrara: Since the resignation of Andrea, the mixed-mode type hint (called declaration in the proposal) proposal has been left abandoned. Considering that the ending votes were 67/34 (66.3%) with several no-votes being only due to reasonably minor issues with the proposal, I would like to re-propose her RFC with three minor modifications: What about Sara's Scalar Type Hints v0.4 discussion? I find it disturbing that you take over the RFC without even mentioning this discussion. Please coordinate with Sara first before starting another attempt that will be doomed because some people rather wait for Sara's RFC and a ?php // strict option. Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
Am 19.02.2015 um 05:21 schrieb Dennis Birkholz: Am 18.02.2015 um 21:44 schrieb Anthony Ferrara: Since the resignation of Andrea, the mixed-mode type hint (called declaration in the proposal) proposal has been left abandoned. Considering that the ending votes were 67/34 (66.3%) with several no-votes being only due to reasonably minor issues with the proposal, I would like to re-propose her RFC with three minor modifications: What about Sara's Scalar Type Hints v0.4 discussion? I find it disturbing that you take over the RFC without even mentioning this discussion. Please coordinate with Sara first before starting another attempt that will be doomed because some people rather wait for Sara's RFC and a ?php // strict option. I just saw the reddit where you mention that v0.4 is practically abandoned now, so I will just renounce my previous mail! Will you consider to let the people vote on how to enable strict mode like discussed in the v0.4 discussion? Like this here from the Reviving scalar type hints thread? Am 17.02.2015 um 00:58 schrieb Sara Golemon: Straw poll: 1) ?php strict; 2) ?php-strict 3) use strict; (psuedo-namespace) 4) ?php // strict (I don't actually like HHVM's style, but if you do...) 5) declare(strict=true); (As a top-level declare only) 6) declare(strict=true); (exactly as in v0.3 -- maybe you liked it) 7) your write-in vote here Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5
On 18 February 2015 at 22:21, Albert Casademont Filella albertcasadem...@gmail.com wrote: So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes combined need 2/3 of the votes. Then a simple majority of 50%+1 between the different Yes votes is needed. This is pretty flawed, but nice try. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
