Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68882 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57678 invoked from network); 3 Sep 2013 07:44:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Sep 2013 07:44:18 -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.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:60130] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D4/97-29856-05395225 for ; Tue, 03 Sep 2013 03:44:17 -0400 Received: (qmail 17267 invoked by uid 89); 3 Sep 2013 07:44:13 -0000 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@109.152.18.233) by mail4.serversure.net with ESMTPA; 3 Sep 2013 07:44:13 -0000 Message-ID: <52259425.9050209@lsces.co.uk> Date: Tue, 03 Sep 2013 08:47:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: PHP Internals References: <52243BA6.5040905@sugarcrm.com> <5224F2EC.2090609@sugarcrm.com> <52250A97.8050406@sugarcrm.com> <52251149.4080308@sugarcrm.com> <522517D5.7020603@lsces.co.uk> <80742DA8-3947-4569-8643-4075FF213259@newtekemail.com> In-Reply-To: <80742DA8-3947-4569-8643-4075FF213259@newtekemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Skipping parameters take 2 From: lester@lsces.co.uk (Lester Caine) Robert Williams wrote: > PHPDoc doesn't support parameter blocks, which means that IDEs can't offer the same level of assistance with code-completion that they offer for both objects and straight parameters -- another huge downside. PHPDoc's does 'not' not support parameter blocks ... you just document them properly in the first place. Switching these to formalised objects introduces another level of complexity that detracts from their use rather than enhancing it, but again that is more to do with maintaining BC. Something that has become a second class citizen nowadays? Much of the work I've been wasting time on over the past years is re-factoring legacy code to make it E_STRICT compliant. Switching TO using arrays has been part of that exercise and was helpful in getting around the warnings raised to the original code. Much of the material I'm working with is arrays of data into and out of a database, so not naturally an 'object'? OK adding 'default' or going on to finally force named parameters on us is not going to break anything but it's creating yet more new styles of coding when what we NEED is to simplify and get back to a style of working that we can agree on and start producing applications rather than reinventing the engine every year :( Currently - as I've said many times - there is no 'style guide' to provide a best practice we can work to. PSR is probably the closest we have but even that is a clique of users with a particular agenda which is why it's not formally accepted by the general development team? Redoing everything again to conform with that would be another year or so's work for me :( Coding used to be fun - now it's just a chore :( -- 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