Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83886 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79861 invoked from network); 26 Feb 2015 11:09:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 11:09:46 -0000 Authentication-Results: pb1.pair.com header.from=kontakt@beberlei.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=kontakt@beberlei.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.176 cause and error) X-PHP-List-Original-Sender: kontakt@beberlei.de X-Host-Fingerprint: 74.125.82.176 mail-we0-f176.google.com Received: from [74.125.82.176] ([74.125.82.176:33056] helo=mail-we0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 41/B2-65287-8FEFEE45 for ; Thu, 26 Feb 2015 06:09:45 -0500 Received: by wevk48 with SMTP id k48so9581694wev.0 for ; Thu, 26 Feb 2015 03:09:41 -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=ztZ3UyXElYpg2Hrtp1TqTXtVwHFMB7GZSsdR+wN+vRw=; b=GzoegCXZRVtd/VIlPYbfM83O/xovfD2gk0qTXOQyUtVFJAggWIPV2f1N7OEIlpiO7I ue+0qrTAeT9Vo48Y6Zs6DDIUAFHOm8gUqNx0xhVf25J54VUfhI9Jx/Yu7nBfrWBRjgVD KX8I0kBEOtXsiwevrQ9BeDtOOlnOvhAEn9UwsTBJe/yaIB6xKXtk1mHViwooQYwCMx0U m+Arr0RBHhBwTwSy2U5JwbbPP1K/WuHSBthQ6OjRiAnUuvem/K5vBTLcbQVZ6d3snuHy nRizkZ3D3FIpYKZff1zEx3Rtz34rIEMggm3JiflPwaFOLZxeGzZOTJg+txC09VbkBDJT 9v7g== X-Gm-Message-State: ALoCoQnXc6tX69TuekwtikpuF+LUiUkstZyun51BWxNTfeJhQ6CHZuqdRNcBp/duqerhBenloYae MIME-Version: 1.0 X-Received: by 10.180.91.79 with SMTP id cc15mr50264822wib.52.1424948981580; Thu, 26 Feb 2015 03:09:41 -0800 (PST) Received: by 10.194.192.202 with HTTP; Thu, 26 Feb 2015 03:09:41 -0800 (PST) X-Originating-IP: [77.11.23.161] In-Reply-To: References: Date: Thu, 26 Feb 2015 12:09:41 +0100 Message-ID: To: Dmitry Stogov Cc: Anthony Ferrara , PHP Internals Content-Type: multipart/alternative; boundary=f46d043be246dedb8c050ffbc99f Subject: Re: [PHP-DEV] Strict typing and callback vs declare() From: kontakt@beberlei.de (Benjamin Eberlei) --f46d043be246dedb8c050ffbc99f Content-Type: text/plain; charset=UTF-8 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. 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. 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. > > Thanks. Dmitry. > > > --f46d043be246dedb8c050ffbc99f--