Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101541 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97023 invoked from network); 5 Jan 2018 09:50:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jan 2018 09:50:21 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain lsces.co.uk designates 185.153.204.204 as permitted sender) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 185.153.204.204 mail4.serversure.net Linux 2.6 Received: from [185.153.204.204] ([185.153.204.204:50340] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EB/37-45945-B5A4F4A5 for ; Fri, 05 Jan 2018 04:50:20 -0500 Received: (qmail 12142 invoked by uid 89); 5 Jan 2018 09:50:16 -0000 Received: by simscan 1.3.1 ppid: 12136, pid: 12139, t: 0.0520s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 5 Jan 2018 09:50:16 -0000 To: internals@lists.php.net References: <9a3a8760-f65a-a5c0-b318-1830a9a986c3@gmail.com> <9352F6DF-9940-49A2-9B1D-FA9258E9738E@lerdorf.com> Message-ID: Date: Fri, 5 Jan 2018 09:50:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <9352F6DF-9940-49A2-9B1D-FA9258E9738E@lerdorf.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax From: lester@lsces.co.uk (Lester Caine) On 05/01/18 01:21, Rasmus Lerdorf wrote: > The reason we don’t have typed properties/variables is that it would require adding type checks on almost every access to the underlying zval. That is a huge perf hit compared to only doing it on method/function egress points as we do now. I think that in hindsight all I have been looking to out of this is that 'zval' has additional capability to standardise validation. 'Simply' adding a crude type check with it's overheads does not remove the validation requirements which still need to be handled much of the time. It the type check ALSO included validation, then the performance hit would be mitigated by the reduction in user side code. But 'error' may not be the right response EVEN with just the simple type check and that is why current typing hacks don't fit MY method of working. I have validation on key paths, but each is isolated from other paths while a core standard method of validation would simplify things in a way 'strong typing' does not! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk