[RFC][Accepted] Scalar Type Declarations V0.5

Hi Andre,

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 dennis@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
yohgaki@ohgaki.net

Pavel,

On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre.php@gmail.com
wrote:

On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
ircmaxell@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

--

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

Pavel,

On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre.php@gmail.com
wrote:

On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
ircmaxell@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

--

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

On Wednesday, March 18, 2015, Patrick ALLAERT patrickallaert@php.net
wrote:

Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajousek@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