Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83890 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86625 invoked from network); 26 Feb 2015 11:34:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 11:34:36 -0000 Authentication-Results: pb1.pair.com smtp.mail=kontakt@beberlei.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=kontakt@beberlei.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.173 cause and error) X-PHP-List-Original-Sender: kontakt@beberlei.de X-Host-Fingerprint: 74.125.82.173 mail-we0-f173.google.com Received: from [74.125.82.173] ([74.125.82.173:36033] helo=mail-we0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5D/04-65287-BC40FE45 for ; Thu, 26 Feb 2015 06:34:36 -0500 Received: by wevk48 with SMTP id k48so9753521wev.3 for ; Thu, 26 Feb 2015 03:34:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qEoxzCYm2c7V+THaLqCCoYx2FpAgNM/vmCLpAD3REJ4=; b=LtpOULSGvmsJ9C81SQyNrGsPX9+azQQtI3+c5QGwB92Ls3fbnYmFeZkI2zOPX1sbUY SS2NNOUIM2VoNEyrfmpnsL+En9+pK9ikC2xMTLD65Rfc1cnH+qC9Wugq1m9XPCswKZv6 vLx1HaTBIWW9bQTdHy+La3Yr+YFoD3V1jqA6M0myuAByvuIWuOyZeHy6MuUZ5fNlTNDI FSBwpkTiXqPTmLUFnRtiwcv1VFob+J5ZPCXaJWBRTRiu/SUss3cvAebM3D4w+HT0ijbJ vHqH+gy7+7l18SCvAxA1Wu802BM9WwS0qTmfsMtayk01M+p1OWDgSAcT8QOFUZYXuIEk Vzdg== X-Gm-Message-State: ALoCoQnomDZImQACzCQqCKloHiLz/E3FN1rArJdTPVPX3COgm3Tk9na7hpXHc0lrQH3LBZsl4xI0 MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr15810972wjc.4.1424950472425; Thu, 26 Feb 2015 03:34:32 -0800 (PST) Received: by 10.194.192.202 with HTTP; Thu, 26 Feb 2015 03:34:32 -0800 (PST) X-Originating-IP: [77.11.23.161] In-Reply-To: References: Date: Thu, 26 Feb 2015 12:34:32 +0100 Message-ID: To: Dmitry Stogov Cc: Anthony Ferrara , PHP Internals Content-Type: multipart/alternative; boundary=089e01419d1cbb5614050ffc22e2 Subject: Re: [PHP-DEV] Strict typing and callback vs declare() From: kontakt@beberlei.de (Benjamin Eberlei) --089e01419d1cbb5614050ffc22e2 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov wrote: > > > On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei > wrote: > >> >> >> On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov wrote: >> >>> >>> >>> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei >>> wrote: >>> >>>> >>>> >>>> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov >>>> wrote: >>>> >>>>> Hi Anthony, >>>>> >>>>> What do you think about using a user level callback for strict type >>>>> checks >>>>> instead of declare(). It won't allow changing behavior per file, but >>>>> this >>>>> has its own cons and pros. >>>>> >>>>> >>>> set_strict_type_checker(function ($class_name, $function_nume, >>>>> $arg_num, >>>>> $expected_type, $value, $file, $line) { >>>>> ... >>>>> return false; >>>>> }); >>>>> include("orig_index.php"); >>>>> ?> >>>>> >>>>> If callback is not set, arguments are converted according to standard >>>>> rules, if set and returns false - fatal error or exception is thrown. >>>>> >>>>> The implementation should be simpler and more efficient than using >>>>> declare(). >>>>> >>>>> Thanks. Dmitry. >>>>> >>>> >>>> This ruins portability with third party libraries completely. >>>> >>> >>> Not completely, because checker may be smart enough to return "true" for >>> third party files. >>> >>> >> set_strict_type_checker(function ($class_name, $function_nume, >>> $arg_num,$expected_type, $value, $file, $line) { >>> if (!my_own_file($filename)) { >>> return true; >>> } >>> ... >>> return false; >>> }); >>> include("index.php"); >>> ?> >>> >>> And you won't have to modify each file in your project adding >>> declare(strict_types=1). >>> >> >> Yes, but you need a mechanism for each third party library to register >> their typechecker code and then build a generic type checker system using >> the right checks for the right library. This will produce really slow code >> considering it will trigger this on every argument. >> > > Only for strictly wrong arguments. > > >> Also i find declare(strict_types=1) is already adding another stack in my >> mind to think about, now having to think about every file/lirary having a >> different kind of validation makes it even more complicated. >> > > You 'll have to think about each file anyway. To add or not to add > declare(strict_types=1). > Yes, but It has only exactly one ruleset to keep in mind. With your approach the ruleset space is infinite. Much more complex. > Callback would allow to care about strict type checks in one separate > place. > It's like to keep a screw key with every nut in your car instead of > keeping toolbox. > > >> >> Additionally it destroys the AOT compile benefit of static type hints, >> since you cannot compile code down to C again, because the >> conversion/validation is not necesarily deterministic. >> > > Oh god... > If you know the type of passed and expected argument at compile time, > strictness doesn't make any difference (you may only report a error at > compile time). > If you don't know type of passed or expected argument at compile time, > you'll have to check their equality at run-time anyway. > This is not my argument, just saying that what strict Types would allow (static analysis and AOT) is not possible when the static rules are not determinstic. This will lead to every pro static person to reject your approach. declare(strict_types=1) is about having a single, pre-determined, deterministic ruleset. > > Thanks. Dmitry. > > >> >> >>> >>> Thanks. Dmitry. >>> >>> >>> >> > --089e01419d1cbb5614050ffc22e2--