Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83921 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71410 invoked from network); 26 Feb 2015 19:54:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 19:54:20 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.215.52 mail-la0-f52.google.com Received: from [209.85.215.52] ([209.85.215.52:39767] helo=mail-la0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 35/BD-32582-BE97FE45 for ; Thu, 26 Feb 2015 14:54:20 -0500 Received: by labgq15 with SMTP id gq15so13338886lab.6 for ; Thu, 26 Feb 2015 11:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HBwz7503TQ90vNnjeglKTaVfqyVhsElH0pvPZQsHMpw=; b=GuithecIPpLG8IGoiEOcKU2agf7i2xusoxYKd1H5xHiC+agx4qv2MGp/wPkh3k8hwS koVu31Le9XjG61T63MPti+cbBS8QOd4rnqFxlL1ClMPlgKzUjoTD6Ip7acONlPRoOlvi NHqf+CgjNnI0cVyquJuTnUDPV7MS0CjRZwVoOoJagCMAnGz1iSZv4+50gbkwqkSQvFq1 6FeAbkWFfO5TJtFa37qj7C020yFG9mHKDq+3Ue8r0s30SZZLrSLGfQ5Xn9pSyyGhk5yh 9AJ8ARzBVtxuRQzrzG9lS4sevUsezJTYRSvBtyQdyD+6snEkDUDwvfV4+F+h4ZNZDiFc FXhg== MIME-Version: 1.0 X-Received: by 10.152.246.41 with SMTP id xt9mr3137712lac.110.1424980456977; Thu, 26 Feb 2015 11:54:16 -0800 (PST) Received: by 10.25.43.9 with HTTP; Thu, 26 Feb 2015 11:54:16 -0800 (PST) In-Reply-To: References: <3d639901ae85227b219e7ee59b3140fe@mail.gmail.com> Date: Thu, 26 Feb 2015 14:54:16 -0500 Message-ID: To: Zeev Suraski Cc: Mike Willbanks , Dan Ackroyd , Theodore Brown , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] A different user perspective on scalar type declarations From: ircmaxell@gmail.com (Anthony Ferrara) Zeev, >> With the current coercive proposal, you will still need to worry about the >> types: https://wiki.php.net/rfc/coercive_sth#coercion_rules > > That's true, but a lot, lot less. We apparently have a different definition of "less". Your proposal requires you to worry about every type in every line of code that ever existed. Yes, there are fewer dangerous type change errors, but you need to look at every line of your application to find them. In my dual-mode proposal, the only place you need to worry about this is code that's explicitly opted-in to the rules via a per-file switch. So by default, nobody gets any change. If you opt-in however, then you get the full rules. >> Passing boolean(false) where an integer is expected will generate an >> error. >> This is a common practice, specifically around internal functions. >> Example: >> https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4eeea5fd9f >> e8916859a07430b94cf42/src/Util/ErrorHandler.php#L58 > > It's actually not nearly as common as one might think, and arguably - it's > may be hiding bug or at least some misunderstanding about the semantics of > the argument (not always, but sometimes). Warning about it (as deprecated) > makes perfect sense. I'm going to send some data from real world apps later > today or early tomorrow. Spoiler - not a lot of breakage at all, and > coercive rules seem to have a remarkably good signal to noise ratio. If Symfony or PHPUnit didn't error in these cases in more than one place, I'd be inclined to agree with you (about not being as common as one might think). But considering two of the best architected and tested applications in the ecosystem both error in non-trivial amounts, I think it's fair to say... >> The difference is with the dual-mode RFC you can choose not to have to >> cast >> and keep everything as-is today (or more specifically, you need to >> explicitly >> choose strict mode). And you can have user-land behave identically to >> internals **in both cases**. > > Put another way, coercive gets to keep a single, sensible conversion > rule-set in PHP - with relatively minor updates needed over the course of > several years. And contrary to what might be implied here, it would require > a LOT less casting - while still taking advantage of much better data > sanitation. I think you're REALLY downplaying the level of effort that's required for the updates you're requiring users make. And that scares me. Anthony