Hi Rasmus,
> On 8 Feb 2015, at 02:38, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
>
> On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
>> I'm wishing more and more that the RFC doesn't pass (even though I'd
>> LOVE to have typehints in PHP as a userland developer) and someone
>> else will make a better version of typehints RFC for PHP 7, because
>> this one feels really like you took an ok-ish RFC (one that would be
>> good for PHP) and slapped a strict typing on it without enough
>> research about strong typing in other languages. And as I said myself
>> multiple times in the past, the declare syntax IS just ugly (and
>> changing how code works by writing one line is an ugly principle as
>> well, IMHO). :(
>
> I am not sure I would go that far. Andrea did plenty of research and has
> tons of experience in other languages, I just think this approach is
> misguided. I also wonder just how many people of those who voted even
> bothered to download and try the patch. I tried it a while back on some
> existing code and it was a nightmare. Does everyone realize that these
> simple things break?
>
> tan(1);
> echo strstr("test", "est", 1);
Banning int->float and float->int is both a pain point and sometimes a
life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you
discover if your ints floats would be silently truncated (as I did with
PictoSwap).
I wouldn’t say that int->string not working is a problem, though. Seeing
something like strstr(“test”, “est”, 1); is rather confusing. Looking at it,
I’d think the third parameter is some sort of number for you to want to pass an
integer to it. If I want a string, I’ll use one.
> Having absolutely no coercion for int to float and 0/1 to false/true,
> especially for internal functions, is just too pedantic to me. I also
> find this a bit hypocritical:
>
> declare(strict_types=true);
>
> outputs:
>
> Fatal error: strict_types declaration must have 0 or 1 as its value
>
> That is obviously nit-picking, but if we are going to get this pedantic…
Yes, that is a cruel irony that I did notice when I changed it. I sacrificed
strictness/“correctness” there for brevity. The reason you can’t use a boolean
is that I think it’s better if only two forms are allowed (=0 and =1) - less
forms to remember, less ambiguity.
> And, you also have to realize that it isn't actually per file. For
> example, this:
>
> <?php
> function myErrorHandler($errno, $errstr, $errfile, $errline) {
> if ($errno===E_RECOVERABLE_ERROR) {
> echo "\ncatchable fatal error\n";
> return true;
> }
> return false;
> }
> set_error_handler('myErrorHandler');
>
> echo tan(1);
> declare(strict_types=1);
> echo tan(1);
> declare(strict_types=0);
> echo tan(1);
>
> This will output:
>
> 1.5574077246549
> catchable fatal error
> 1.5574077246549
>
> The RFC refers to it as a per-file directive, which just means it
> doesn't apply to files you include after setting it. It doesn't mean
> that the entire file is affected. You can flip in and out of strict mode
> at will. Which isn't necessarily a bad thing, but it can certainly get
> confusing.
Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
sense (like encoding, but unlike ticks, it has no effect on the including or
included files). However, it technically affects the remainder of the file, not
the whole file.
> For example. Since everyone has already voted, you can all tell me what
> this does, right?
>
> 1)
> <?php
> function do_something() {
> declare(strict_types=1);
> }
> echo tan(1);
> do_something();
> echo tan(1);
I don’t understand why it’s even allowed for the declare() statement to be used
like that (why is a compile-time option allowed to be within a function? That’s
a recipe for disaster), but that would make the first tan(1); error and halt
program execution.
> How about this:
>
> 2)
> <?php
> echo tan(1);
> do_something();
> echo tan(1);
> function do_something() {
> declare(strict_types=1);
> }
First two calls succeed. Again, declare()’s behaviour is weird… makes me wonder
who thought it was a good idea to allow this.
> or this?
>
> 3)
> <?php
> function do_something() {
> declare(strict_types=1);
> }
> echo tan(1);
> echo tan(1);
That would make the first tan(1); error and halt program execution.
> Answers:
>
> 1) fatal error on the first tan(1)
> 2) no errors
> 3) same as 1)
Hooray, I guessed right.
> Basically declare() does not respect function scope, but it doesn't let
> you know that. There is a reason we haven't used declare() for anything
> real.
I wonder if we should just remove this ability of declare(); or at least
produce some sort of warning (E_DEPRECATED? E_WARNING? E_STRICT?). It’s highly
misleading and I don’t really understand why it’s allowed.
Then again, that would cause problems for ticks, possibly?
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
