Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86088 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35547 invoked from network); 30 Apr 2015 10:20:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Apr 2015 10:20:23 -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:42303] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E6/B7-27026-5E102455 for ; Thu, 30 Apr 2015 06:20:22 -0400 Received: (qmail 27365 invoked by uid 89); 30 Apr 2015 10:20:19 -0000 Received: by simscan 1.3.1 ppid: 27357, pid: 27360, t: 0.0937s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 30 Apr 2015 10:20:18 -0000 Message-ID: <554201E2.5090608@lsces.co.uk> Date: Thu, 30 Apr 2015 11:20:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: internals@lists.php.net References: <55416849.9010808@gmail.com> <554176D6.2030007@gmx.de> <55418CBE.6050609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Adding "numeric" type hint From: lester@lsces.co.uk (Lester Caine) On 30/04/15 08:42, Walter Parker wrote: > I thing using string type hints are are easier to advocate (and I think > they are the correct type if you need to be 32/64 indepentent). > Otherwise, a numeric type doesn't fix the problem. It hides it. It is a > short term that doesn't scale properly. > > Use int hints correctly. There are still new, if we start using the > incorrectly, things will only get worse. The drive by the 'strict' camp to get strict type checking in by any means did mess up the discussion on the full implications of what weak typing fall back was going to provide, so to be honest I see little point in even allowing hinting in my tool set. I still need all of the PHP5 type checking so why not simply maintain that? But now also having to cope with additional platform differences :( A number of areas of hinting are not supported, leaving what we now have for PHP7. The result is less than satisfactory and this is a perfect example! WHY am I restricted to using 'string' for the very thing that I am working with mainly? The whole point with going to 64bit was to properly support 64bit integers, but in an ideal world that would also work on 32bit platforms ... transparently! There are a number of different requirements all being pushed and the result is we don't have an agreed roadmap. BIGINT is a case in point, since it is either '64bit integer' or 'unlimited integer' and the two are mutually exclusive. 32bit platforms NEED a reliable 64bit integer moving forward, but some people seem to think that 32bit PHP can be ignored? If I'm having to drop back to validating all the database data as string values then what is the point of integer hints? Some additional hints will be required in the future, and making 'numeric' an unlimited number makes sense if 'float' and 'int' are restricted to some hardware limit, but additional fixed length hints still makes perfect sense? -- 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