Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86348 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52442 invoked from network); 22 May 2015 08:04:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 May 2015 08:04:59 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; 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:36492] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DB/54-14563-723EE555 for ; Fri, 22 May 2015 04:04:56 -0400 Received: (qmail 15673 invoked by uid 89); 22 May 2015 08:04:52 -0000 Received: by simscan 1.3.1 ppid: 15667, pid: 15670, t: 0.1686s 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; 22 May 2015 08:04:52 -0000 Message-ID: <555EE323.4050400@lsces.co.uk> Date: Fri, 22 May 2015 09:04:51 +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: <555E762F.6060704@gmail.com> In-Reply-To: <555E762F.6060704@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Soft-reserve "void" class name From: lester@lsces.co.uk (Lester Caine) On 22/05/15 01:19, Stanislav Malyshev wrote: >> > I'd like to add "void" to this list, so we have the option to introduce a >> > void return type in PHP 7.x. I've seen some disagreement as to whether this > I think this type makes no sense in PHP, but I don't object to having > note in the docs for people not to name their classes "void" (not that > there's any reason to do it anyway...). I strongly object to introducing > any changes in the code though - warnings, etc. The whole problem here is that anything that is documented gives some legitimacy to the idea that it must be included during the PHP7 cycle. Since there is no consensus on the whole area it would perhaps block a more practical alternative if that surfaces in the next few years? Not that I can see anything that falls in that category either? -- 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