Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80523 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37344 invoked from network); 15 Jan 2015 08:29:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2015 08:29:55 -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.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:40292] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F2/93-14306-F7A77B45 for ; Thu, 15 Jan 2015 03:29:52 -0500 Received: (qmail 19194 invoked by uid 89); 15 Jan 2015 08:29:48 -0000 Received: by simscan 1.3.1 ppid: 19187, pid: 19191, t: 0.0756s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.160.91.166) by mail4.serversure.net with ESMTPA; 15 Jan 2015 08:29:48 -0000 Message-ID: <54B77A7C.406@lsces.co.uk> Date: Thu, 15 Jan 2015 08:29:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: internals@lists.php.net References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2 From: lester@lsces.co.uk (Lester Caine) On 15/01/15 07:26, Pavel KouĊ™il wrote: > And yesterday I was pointed out one thing: the RFC states "With this > approach, an argument is only accepted if its type is exactly the same > as the parameter.". Does this mean you cannot pass integer to a > function with float argument in the strict mode? One of the nice features of PHP when I started using it all those years ago was that I did not have to create separate functions different types did exist in the source data. int/float/num/double and others all needed separate handling in c/c++, and one could not easily add a different 'type' of data. Nowadays I get around many of the problems that are currently all being debated by passing an 'id' or an array of data as the only parameter to a function. If the bigint 'id' is already loaded, the cached version is used, if not it is loaded or an empty default object created. If an array is passed then the relevant fields are actioned. With the current discussions I see what has become a style of working based on how PHP USED to work is now being pushed into the 'that is not the way to do it' box? I have named parameters, they are the elements of the array, order is not relevant, I can skip ones, or add new ones without affecting anything. I can see that for some nailing everything down and avoiding any flexibility is their target while others DO still subscribe to the lighter approach which allows in my book greater flexibility. So perhaps we are at a point where a big switch is needed much like e_strict to isolate the 'strict mode' from 'flexible mode'? I can see third party libraries having to provide different versions of the same code if this particular discussion goes down the wrong path? -- 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