Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi Zeev, On Wed, Mar 18, 2015 at 6:43 PM, Zeev Suraski z...@zend.com wrote: FWIW, as someone who did play with the patch (both patches, of course), I'm not sure why people are claiming you don't understand the RFC. Your comments in the code are 100% accurate, which means you understood exactly how it works. Josh Di Fabio just pointed out to me that the code in question wasn't actually written by you but by Dennis Birkholz, so my statement was incorrect. Still, from what you said it appears to me you still understood the behavior but disagreed with it. I know that at least on my end, that was definitely the case. Yes and I fully agree. Anyway, unlike your proposal, I have to advocate users not to use type hint for database INT8, JSON numeric, etc. It will be tough job... Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi all, On Thu, Mar 19, 2015 at 6:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Mar 18, 2015 at 6:43 PM, Zeev Suraski z...@zend.com wrote: FWIW, as someone who did play with the patch (both patches, of course), I'm not sure why people are claiming you don't understand the RFC. Your comments in the code are 100% accurate, which means you understood exactly how it works. Josh Di Fabio just pointed out to me that the code in question wasn't actually written by you but by Dennis Birkholz, so my statement was incorrect. Still, from what you said it appears to me you still understood the behavior but disagreed with it. I know that at least on my end, that was definitely the case. Yes and I fully agree. Anyway, unlike your proposal, I have to advocate users not to use type hint for database INT8, JSON numeric, etc. It will be tough job... Anyone who are willing to use type hint for any data that has integer/float form, you still have chance to vote to 'yes' for https://wiki.php.net/rfc/coercive_sth Weak mode can be coercive. Coercive mode works better with my type affinity proposal also. https://wiki.php.net/rfc/introduce-type-affinity Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same questions
(in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix bugs
if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it -
but I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi,
Le 18 mars 2015 11:06, Pavel Kouřil pajou...@gmail.com a écrit :
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions
(in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs
if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it -
but I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
You can emulate multiple files support by using eval().
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Cheers,
Florian Margaine
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions (in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs if there are actual ones in the current implementation.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit :
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Your intuition is correct.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Flaw vs. design choice. This is one of the reason that this aspect, amongst
others, has been very debated.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 17/03/15 23:53, André Rømcke wrote: To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to extract just what has now been agreed for that area of type hinting. A base that can be used to review some of the other discussions to put that to bed. Others might appreciate a similar summary of the 'type_error' mode as well? As a base for the documentation on the user manual updates? Not sure what is difficult to extract https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks It's all right there... And there is nothing else in a substantial RFC that relates to weak mode? That part answers what has been agreed (or rather accepted), but not who the weak mode is for, and why. Tried to sum that up last week when there was still discussions on this: http://share.ez.no/blogs/core-development-team/php-7-sth-from-user-perspective TL;DR; weak mode is for api consumers, aka normal php users, while strict is for the actual target users of this features: api (library/framework) creators. Post also argues for why Zeev's adjustments to weak sth handling should still be done, as well as arguing for disallowing/fixing closure hint in strict mode. That is the sort of thing that will help nail down the edge cases in weak mode André ... since the bulk of the RFC spends so much time explaining why 'strict mode' is so much better? Yasuo has pointed out details which are as pointed out perfectly correct, but it is still worth documenting that this is what does happen, and therefore what needs fixing. What I am still having trouble with is just how one reworks phpeclipse and other IDE's so that they know that if the open file AND another file have declare(strict_types = 1); then the rules change. Anybody had a look at that yet for PDT? It's all very well putting it into the core and saying you don't have to use it, but all of the infrastructure now needs to know what to do :( -- 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][Accepted] Scalar Type Declarations V0.5
-Original Message- From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki Sent: Wednesday, March 18, 2015 6:44 AM To: Pierre Joye Cc: PHP internals; Leigh; André Rømcke; Lester Caine Subject: Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5 Hi Pierre, On Wed, Mar 18, 2015 at 1:35 PM, Pierre Joye pierre@gmail.com wrote: On Mar 18, 2015 11:26 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I didn't have my time to spent for the patch. So I don't verify this by myself, but it seems common sense for this RFC. So you voted against it without knowing how it actually works or aims to work? I suggest you to do it now then, before going further with this discussion :) I know we are better to play with patch before vote. I played with Zeev's patch and I was sure it's better ;) How many of voters spend enough time for both patches before vote? Apparently very few. In terms of people who actually reported their findings or explicitly said they played with it here on internals, perhaps a handful. FWIW, as someone who did play with the patch (both patches, of course), I'm not sure why people are claiming you don't understand the RFC. Your comments in the code are 100% accurate, which means you understood exactly how it works. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
FWIW, as someone who did play with the patch (both patches, of course), I'm not sure why people are claiming you don't understand the RFC. Your comments in the code are 100% accurate, which means you understood exactly how it works. Josh Di Fabio just pointed out to me that the code in question wasn't actually written by you but by Dennis Birkholz, so my statement was incorrect. Still, from what you said it appears to me you still understood the behavior but disagreed with it. I know that at least on my end, that was definitely the case. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net
wrote:
Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit :
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Your intuition is correct.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Flaw vs. design choice. This is one of the reason that this aspect,
amongst others, has been very debated.
But if it works this way, the strict mode isn't optional and users of a
library NEED to care which mode the library uses?
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote:
Pavel,
On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1); function foo($fn) { $fn(1);
};
// b.php
?php
require 'a.php'; foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) { $fn(1);
};
// d.php
?php
declare(strict_types=1); require 'c.php'; foo(function (int $a) { return
$a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions (in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it - but
I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
for anyone needing to test on Windows, there was builds for an older RFC
version
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/
but I just made quick builds for the current as well
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/
So you've got the choice.
Cheers
Anatol
Hello,
thanks a lot, I'll play with it this evening. :)
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Pavel,
On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1); function foo($fn) { $fn(1);
};
// b.php
?php
require 'a.php'; foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) { $fn(1);
};
// d.php
?php
declare(strict_types=1); require 'c.php'; foo(function (int $a) { return
$a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions (in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it - but
I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
for anyone needing to test on Windows, there was builds for an older RFC
version
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/
but I just made quick builds for the current as well
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/
So you've got the choice.
Cheers
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote:
Pavel,
On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1); function foo($fn) { $fn(1);
};
// b.php
?php
require 'a.php'; foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) { $fn(1);
};
// d.php
?php
declare(strict_types=1); require 'c.php'; foo(function (int $a) { return
$a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions (in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it - but
I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
for anyone needing to test on Windows, there was builds for an older RFC
version
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/
but I just made quick builds for the current as well
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/
So you've got the choice.
Cheers
Anatol
Hello,
I've tried the build, and it seems like it's in the strict mode 100%
by default, and the declare statement doesn't recognize strict_types
(PHP Warning: Unsupported declare 'strict_types'). Is this
intentional?
Regards
Pavel Koruil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote: Hello, I made that conclusion because in the first example, the library kinda forces strict mode rules on the caller, even if he doesn't want to use strict mode - this makes the interoperability of the two modes problematic. This is incorrect, library force itself to use right types, not you. I don't see any problems here. The only thing that for sure lacks in PHP and that would make STH better is callable signature types. Also, the other possible outcome of the scenario (respecting the mode of the place where the callback is declared), is IMHO problematic as well, because it does not respect the strict mode of the place where it is called, making it inconsistent with how the dual mode RFC works in general. It doesn't matter where the callback or function was declared, it only matters where it was called. It pretty much is consistent.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 Mar 2015 14:32, Pavel Kouřil pajou...@gmail.com wrote:
On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net
wrote:
Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit
:
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Your intuition is correct.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Flaw vs. design choice. This is one of the reason that this aspect,
amongst others, has been very debated.
But if it works this way, the strict mode isn't optional and users of a
library NEED to care which mode the library uses?
If library chose to use strict mode then the odds are it will take care of
passing right types to callbacks and interfaced methods.
Saying that strict mode isn't optional is not true, I don't see why you
have made this conclusion.
RE: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hey Pavel,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
Result: catchable fatal error
Reason: invocation context is in strict mode
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
Result: no error
Reason: invocation context is in weak mode
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Correct :)
-Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 1:13 PM, Nikita Nefedov inefe...@gmail.com wrote:
On 18 Mar 2015 14:32, Pavel Kouřil pajou...@gmail.com wrote:
On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net
wrote:
Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit
:
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Your intuition is correct.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Flaw vs. design choice. This is one of the reason that this aspect,
amongst others, has been very debated.
But if it works this way, the strict mode isn't optional and users of a
library NEED to care which mode the library uses?
If library chose to use strict mode then the odds are it will take care of
passing right types to callbacks and interfaced methods.
Saying that strict mode isn't optional is not true, I don't see why you have
made this conclusion.
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I don't
see any problems here. The only thing that for sure lacks in PHP and that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Pavel Kouřil wrote:
On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote:
for anyone needing to test on Windows, there was builds for an older RFC
version
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/
but I just made quick builds for the current as well
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/
So you've got the choice.
I've tried the build, and it seems like it's in the strict mode 100%
by default, and the declare statement doesn't recognize strict_types
(PHP Warning: Unsupported declare 'strict_types'). Is this
intentional?
I quickly tried both php-7.0.0-dev-nts-Win32-VC11-x64.zip, but it seems
the 2015-03-18 build doesn't handle scalar type hints at all.
?php
function foo(int $n) {
var_dump($n);
}
foo(42);
Catchable fatal error: Argument 1 passed to foo() must be an
instance of int, integer given, called in [...] on line 6 and
defined in [...] on line 3
The 2015-02-09 build works fine, at least for this example.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I
don't
see any problems here. The only thing that for sure lacks in PHP and that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the desired
behaviour for your callback should be to accept anything and treat it as an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's intended
behaviour for the callback. Using a type declaration as a means to force a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 4:28 PM, Chris Wright c...@daverandom.com wrote:
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I
don't
see any problems here. The only thing that for sure lacks in PHP and
that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the desired
behaviour for your callback should be to accept anything and treat it as an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's intended
behaviour for the callback. Using a type declaration as a means to force a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
there is even a better argument for this, say you can add a callback to
your franework to register actions and it has to be:
function (Request $request, Response $response) {
}
This is the public interface of the callback so to speak. If you add
something different, you get a catchable fatal error, because you use that
library wrong, right now in PHP 5.*.
I don't see how strict mode enabled in a library, forcing you to define the
right signature for scalars is problematic from any POV. Granted you can
even just omit the scalar type hints completely and it would work.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, March 18, 2015 14:33, Pavel Kouřil wrote: I've tried the build, and it seems like it's in the strict mode 100% by default, and the declare statement doesn't recognize strict_types (PHP Warning: Unsupported declare 'strict_types'). Is this intentional? No, that's probably me building the wrong branch. I've redone and reuploaded, it should be fine. Thanks. Anatol. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
2015-03-18 16:28 GMT+01:00 Chris Wright c...@daverandom.com:
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I
don't
see any problems here. The only thing that for sure lacks in PHP and
that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the desired
behaviour for your callback should be to accept anything and treat it as an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's intended
behaviour for the callback. Using a type declaration as a means to force a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Yet, this code has a major flaw: the type of $b cannot be statically
inferred.
No matter how strict the new mode is, it can only catch errors at
runtime. This is usually too late. Having the ability to find error at
design time is priceless. For me, this is the primary reason I am using
type hints.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 Mar 2015, at 3:44 pm, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Wed, Mar 18, 2015 at 1:35 PM, Pierre Joye pierre@gmail.com wrote:
On Mar 18, 2015 11:26 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I didn't have my time to spent for the patch. So I don't verify this
by myself, but it seems common sense for this RFC.
So you voted against it without knowing how it actually works or aims to
work? I suggest you to do it now then, before going further with this
discussion :)
I know we are better to play with patch before vote.
I played with Zeev's patch and I was sure it's better ;)
How many of voters spend enough time for both patches before vote?
The reason I admit that I didn't spent time to play with the patch is
following behavior does not make sense to me much and I have
doubt for it.
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
Correct. There are no function calls in the file, so there's nothing for
declare strict to act on.
?php
require lib.php;
foo(123); // will work
?
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
Could someone knowledgeable shed light on this?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Shed light on what exactly? Why it behaves this way?
The second file passes because it is in the default weak mode, so it will
coerce to an int, so the type hint is satisfied.
The third file will error because you have asked it to error when you pass the
wrong scalar type to a function.
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi, 2015-03-18 20:42 GMT+01:00 Lazare Inepologlou linep...@gmail.com: However, it seems that the second form is possible to fail, and that depends on the mode (strict or not) of the library that contains the function a. It does not depend on the mode that I have chosen to work with. The two closures will not work in the same way and that's a kind of a WTF moment. If the library documents that it is passing an int or an intable value in non-strict to the callback and it does not do so it has a bug. If the library does not declare a type and you hint an int and it passes something else, you created a bug. However, to work in a real code base some discipline and clean documentation from the library author is required. But I agree that this is currently fragile. Having a way to hint a callables signature may not solve the issue , but make it easier to catch and shift most, if not all, responsibility to the library author. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
2015-03-18 18:30 GMT+01:00 Chris Wright c...@daverandom.com:
On 18 March 2015 at 17:07, Lazare Inepologlou linep...@gmail.com wrote:
2015-03-18 16:28 GMT+01:00 Chris Wright c...@daverandom.com:
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library
kinda
forces strict mode rules on the caller, even if he doesn't want to
use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you.
I
don't
see any problems here. The only thing that for sure lacks in PHP and
that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the
library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't
declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the
desired
behaviour for your callback should be to accept anything and treat it as
an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's
intended
behaviour for the callback. Using a type declaration as a means to force
a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Yet, this code has a major flaw: the type of $b cannot be statically
inferred.
No matter how strict the new mode is, it can only catch errors at
runtime. This is usually too late. Having the ability to find error at
design time is priceless. For me, this is the primary reason I am using
type hints.
In the case where the caller may or may not be passing an int (i.e. the
case where the original example would error because of strict mode in the
lib), the type cannot be inferred through static analysis no matter what
you do, at least not correctly, because it has no definite type. Since
there is currently no number union type it is mixed, which is the
default type for any variable.
Let me be more clear. The type of $b cannot be statically inferred here:
a(function($b) {return ((int)$b) * 2; })
But it can be inferred here:
a(function(int $b) {return $b * 2; })
So I would always prefer to use the second form, especially if the closure
was more complex.
However, it seems that the second form is possible to fail, and that
depends on the mode (strict or not) of the library that contains the
function a. It does not depend on the mode that I have chosen to work with.
The two closures will not work in the same way and that's a kind of a WTF
moment.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Lazare INEPOLOGLOU
Ingénieur Logiciel
Also, the other possible outcome of the scenario (respecting the
mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC
works
in general.
It doesn't matter where the callback or function was declared, it
only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 March 2015 at 17:07, Lazare Inepologlou linep...@gmail.com wrote:
2015-03-18 16:28 GMT+01:00 Chris Wright c...@daverandom.com:
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library
kinda
forces strict mode rules on the caller, even if he doesn't want to
use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I
don't
see any problems here. The only thing that for sure lacks in PHP and
that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't
declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the desired
behaviour for your callback should be to accept anything and treat it as
an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's
intended
behaviour for the callback. Using a type declaration as a means to force a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Yet, this code has a major flaw: the type of $b cannot be statically
inferred.
No matter how strict the new mode is, it can only catch errors at
runtime. This is usually too late. Having the ability to find error at
design time is priceless. For me, this is the primary reason I am using
type hints.
In the case where the caller may or may not be passing an int (i.e. the
case where the original example would error because of strict mode in the
lib), the type cannot be inferred through static analysis no matter what
you do, at least not correctly, because it has no definite type. Since
there is currently no number union type it is mixed, which is the
default type for any variable.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi Andre,
On Wed, Mar 18, 2015 at 8:53 AM, André Rømcke andre.rom...@ez.no wrote:
TL;DR; weak mode is for api consumers, aka normal php users, while strict
is
for the actual target users of this features: api (library/framework)
creators.
How could it possible?
On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
lib.php
?php
declare(strict_types = 1);
function add(int $a, int $b) {
}
?php
add($_GET['a'], $_GET['b']);
that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.
that is not right and has been discussed a thousand times over.
The declare changes the rules only for function calls in the file it is
declared in.
so:
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
Very easy, explained a thousand times over. Bringing up the same false
arguments up again and again does really not help the discussion.
I didn't have my time to spent for the patch. So I don't verify this
by myself, but it seems common sense for this RFC.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mar 18, 2015 11:26 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I didn't have my time to spent for the patch. So I don't verify this by myself, but it seems common sense for this RFC. So you voted against it without knowing how it actually works or aims to work? I suggest you to do it now then, before going further with this discussion :)
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 17/03/15 02:50, Stanislav Malyshev wrote: Let's get on the road for PHP 7 GA and make it the best PHP release ever. To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to extract just what has now been agreed for that area of type hinting. A base that can be used to review some of the other discussions to put that to bed. Others might appreciate a similar summary of the 'type_error' mode as well? As a base for the documentation on the user manual updates? -- 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][Accepted] Scalar Type Declarations V0.5
On Mar 17, 2015, at 18:04 , Leigh lei...@gmail.com wrote: On 17 March 2015 at 08:37, Lester Caine les...@lsces.co.uk wrote: To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to extract just what has now been agreed for that area of type hinting. A base that can be used to review some of the other discussions to put that to bed. Others might appreciate a similar summary of the 'type_error' mode as well? As a base for the documentation on the user manual updates? Not sure what is difficult to extract https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks It's all right there... That part answers what has been agreed (or rather accepted), but not who the weak mode is for, and why. Tried to sum that up last week when there was still discussions on this: http://share.ez.no/blogs/core-development-team/php-7-sth-from-user-perspective TL;DR; weak mode is for api consumers, aka normal php users, while strict is for the actual target users of this features: api (library/framework) creators. Post also argues for why Zeev's adjustments to weak sth handling should still be done, as well as arguing for disallowing/fixing closure hint in strict mode. ar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 17 March 2015 at 08:37, Lester Caine les...@lsces.co.uk wrote: To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to extract just what has now been agreed for that area of type hinting. A base that can be used to review some of the other discussions to put that to bed. Others might appreciate a similar summary of the 'type_error' mode as well? As a base for the documentation on the user manual updates? Not sure what is difficult to extract https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks It's all right there...
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi Anthony, On Tue, Mar 17, 2015 at 6:03 AM, Anthony Ferrara ircmax...@gmail.com wrote: Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Congratulations. Even though I dislike stirct_types part, I appreciate your efforts. Since weakly typed mode is too weak to be useful for detecting possible errors and strict type mode is overridden by any caller(parent script), it's still reasonable to have CoerciveSTH RFC. I hope many of us see the benefits of the RFC also. BTW, I suggest to remove the word strict from strict_types at least as it is not strict at all if caller(parent script) does not specify strict_types=1. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi! Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Despite my previous disagreement with this RFC, I'd like to thank Anthony for all his work on it and persistence and congratulate us all for finally arriving at the decision. I'd like also to thank everybody who contributed to the discussion and participated in the probably most representative vote ever held. Let's get on the road for PHP 7 GA and make it the best PHP release ever. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Thank you Andrea and Anthony. Your efforts are much appreciated! - Jon On Mon, Mar 16, 2015 at 4:03 PM, Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Connect with me on *http://twitter.com/jwage* http://twitter.com/jwage
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Tue, Mar 17, 2015 at 9:45 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Anthony, On Tue, Mar 17, 2015 at 6:03 AM, Anthony Ferrara ircmax...@gmail.com wrote: Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Congratulations. Even though I dislike stirct_types part, I appreciate your efforts. Same here. anyway, I think there is no time doing any changes on this. Let's wait and see, how the community use this strict_types.. anyway, I am glad this thread is finally done. thanks Since weakly typed mode is too weak to be useful for detecting possible errors and strict type mode is overridden by any caller(parent script), it's still reasonable to have CoerciveSTH RFC. I hope many of us see the benefits of the RFC also. BTW, I suggest to remove the word strict from strict_types at least as it is not strict at all if caller(parent script) does not specify strict_types=1. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 3/16/15 4:03 PM, Anthony Ferrara wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony Huzzah! Huge props to everyone that made this happen, especially Andrea for figuring out how to actually do it and Anthony for impressive perseverance. Does this mean this RFC can/should be withdrawn as redundant: https://wiki.php.net/rfc/reserve_more_types_in_php_7 --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mon, Mar 16, 2015 at 5:04 PM Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Wow, 156 votes. As a non-internals developer that's been watching this RFC process for quite some time, I'd just like to say thank you. Thank you to you Anthony, and to Andrea, and to the entire collection of dedicated internals developers and community members who worked so hard to make this possible. This is a HUGE win for PHP. I can't wait to start using PHP 7. :) Oh, and Congratulations! - Trevor
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Congratulations Anthony, and to Andrea for her initial proposal. Finally, we have scalar type hints in PHP. PHP 7 is going to be a real game changer! Chris On 16 Mar 2015, at 9:03 pm, Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- 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][Accepted] Scalar Type Declarations V0.5
Congratulations Antony, Andrea and (yes) Zeev! Thanks to everyone involved, this is a great step forwards and a perfect wrap for PHP 7.0 RFC proposal freeze :) André On Mar 16, 2015, at 23:05 , Chris Harvey ch...@chrisnharvey.com wrote: Congratulations Anthony, and to Andrea for her initial proposal. Finally, we have scalar type hints in PHP. PHP 7 is going to be a real game changer! Chris On 16 Mar 2015, at 9:03 pm, Anthony Ferrara ircmax...@gmail.com wrote: All, Voting has been closed on the scalar type declarations v0.5 RFC: https://wiki.php.net/rfc/scalar_type_hints_v5 At a final score of 108:48, it has been accepted for PHP 7. Thank you. Anthony -- 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
