Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86798 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73486 invoked from network); 22 Jun 2015 22:14:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jun 2015 22:14:36 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:56213] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 87/39-07834-AC888855 for ; Mon, 22 Jun 2015 18:14:35 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 7B5216D2038; Tue, 23 Jun 2015 00:14:31 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on h1123647.serverkompetenz.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.5 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=unavailable version=3.3.2 Received: from w530phpdev (p579F34CF.dip0.t-ipconnect.de [87.159.52.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id 709AE23D615B; Tue, 23 Jun 2015 00:14:28 +0200 (CEST) To: "'Rasmus Lerdorf'" , "'Dmitry Stogov'" Cc: "'Bob Weinand'" , "'Kalle Sommer Nielsen'" , "'Stanislav Malyshev'" , "'Nikita Popov'" , "'PHP internals'" References: <5586E5D1.4010901@lerdorf.com> <55870947.4060304@lerdorf.com> <5587334C.2080401@lerdorf.com> <55873676.6050706@gmail.com> <55876B29.90804@lerdorf.com> <55881A72.4090403@lerdorf.com> <5588477E.7050109@lerdorf.com> <55885D88.8060902@lerdorf.com> In-Reply-To: <55885D88.8060902@lerdorf.com> Date: Tue, 23 Jun 2015 00:14:24 +0200 Message-ID: <02ae01d0ad38$ce8a7a60$6b9f6f20$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKIM6boEtfxlpxsqPDy0Hn99EfxzgHhfpUzAL96+I0BczVjFwFWuKMPAeopdgEBtj7QvQJttk7+Acsp98kCdA3tuQEBpdvvAop/FvQBLcOH3wF6XxzIm5qdnMA= Content-Language: en-us Subject: RE: [PHP-DEV] hasType() for internal function parameters? From: anatol.php@belski.net ("Anatol Belski") Hi, > -----Original Message----- > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] > Sent: Monday, June 22, 2015 9:10 PM > To: Dmitry Stogov > Cc: Bob Weinand; Anatol Belski; Kalle Sommer Nielsen; Stanislav = Malyshev; > Nikita Popov; PHP internals > Subject: Re: [PHP-DEV] hasType() for internal function parameters? >=20 > On 06/22/2015 03:00 PM, Dmitry Stogov wrote: > > > > > > On Mon, Jun 22, 2015 at 8:35 PM, Rasmus Lerdorf > > wrote: > > > > On 06/22/2015 01:27 PM, Dmitry Stogov wrote: > > > Actually, when you added type hints, php compiler stopped = optimizing and > > > using ZEND_DEFINED (and others) instead of internal function = calls, but > > > of course this shouldn't change behavior. I'll need to take a = look into > > > difference. > > > > Right, behaviour shouldn't change, but couldn't we also make it = so that > > arginfo for internal calls is only used by reflection? We can do = all the > > type checking we need right in ZPP as we do now. Let's just = ignore > > arginfo entirely for these calls. > > > > > > In general, we can, if we remove corresponding code in = zend_vm_def.h, > > and also some checks for ZEND_HAS_TYPE_INFO and internal functions = in > > zend_compile.c. >=20 > I think that is the way to go. We didn't have any type info there = before so we are > not losing any functionality, and obviously adding it produces weird = side effects > and slows things down. Plus we should get a very small performance = increase by > removing the type info check entirely. >=20 Are we talking about including this in 7.0? -- If so - do you think we can have it ready short after alpha2? ---- If yes - great, let's do it. ---- If no - lets defer it for 7.1. While I'm still confident we can stabilize it in a beta if there's a = strong support, but better we're "boringly stable" in 7.0 than "shiny = all in". Some side effect we can stabilize in beta? For the core? For = external exts? It clearly suggests itself to check for a couple of step = ahead. Thanks Anatol