Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94194 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33942 invoked from network); 22 Jun 2016 12:27:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jun 2016 12:27:48 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.230 mail4-3.serversure.net Linux 2.6 Received: from [217.147.176.230] ([217.147.176.230:56081] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A9/6D-43024-3448A675 for ; Wed, 22 Jun 2016 08:27:48 -0400 Received: (qmail 12753 invoked by uid 89); 22 Jun 2016 12:27:45 -0000 Received: by simscan 1.3.1 ppid: 12745, pid: 12750, t: 0.1387s 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; 22 Jun 2016 12:27:45 -0000 To: internals@lists.php.net References: <576A6165.8090904@lsces.co.uk> Message-ID: <576A8440.9000801@lsces.co.uk> Date: Wed, 22 Jun 2016 13:27:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties From: lester@lsces.co.uk (Lester Caine) On 22/06/16 11:25, Michał Brzuchalski wrote: > Nobody will pursuade me not that type safety is nothing significant in > programming language. 'type safety' is perhaps the problem here. In a compiled language you are only ever passing a binary value for which the 'type' is a critical element, but move away from the straight jacket of binary variables and allow a user to type a number into a box and use that string value as a variable then the 'type safety' needs to be implemented at the entry point ... including checking the range of the number ... and so there is no point adding code to every usage of a variable that has correctly been validated already. Variables already stored will already have been validated so again the 'additional' check that an integer is an integer has little value? Now start from a situation where we have a proper typed 'var' with the ability to set constraints such as range or string length, then attempts to store the wrong value can be handled ... something that several user coded frameworks already provide ... then even the 'strict' debate has a completely different base? -- 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