Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85000 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11579 invoked from network); 16 Mar 2015 08:04:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Mar 2015 08:04:31 -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:47451] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4D/81-00492-C8E86055 for ; Mon, 16 Mar 2015 03:04:29 -0500 Received: (qmail 27511 invoked by uid 89); 16 Mar 2015 08:04:24 -0000 Received: by simscan 1.3.1 ppid: 27505, pid: 27508, t: 0.0616s 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.178.189.108) by mail4.serversure.net with ESMTPA; 16 Mar 2015 08:04:24 -0000 Message-ID: <55068E88.3090401@lsces.co.uk> Date: Mon, 16 Mar 2015 08:04:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC][VOTE] In Operator From: lester@lsces.co.uk (Lester Caine) On 16/03/15 00:16, Marco Pivetta wrote: > Syntactic sugar won't really make things easier when adopting the language, > and I don't like this sort of additional cognitive load either. > > In short, I stand firm on my "if you can implement it in userland, don't > implement it in the language" idea. Some of this Syntactic sugar would in the past have been developed in PEAR, but the support for 'userland' solutions via that path seems to have lost favour, with even the suggestion that PEAR should be dropped? Perhaps if PEAR contained examples of good practice in these areas it would help. I'd even perhaps go as far as suggesting that some of the more exotic developments in core would benefit from up to date demo's of their use in PEAR? -- 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