Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61765 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19418 invoked from network); 25 Jul 2012 15:11:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jul 2012 15:11:04 -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 213.123.26.185 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 213.123.26.185 c2beaomr07.btconnect.com Received: from [213.123.26.185] ([213.123.26.185:13640] helo=mail.btconnect.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DE/86-19281-78C00105 for ; Wed, 25 Jul 2012 11:11:04 -0400 Received: from host81-138-11-136.in-addr.btopenworld.com (EHLO _10.0.0.5_) ([81.138.11.136]) by c2beaomr07.btconnect.com with ESMTP id IJQ57052; Wed, 25 Jul 2012 16:11:00 +0100 (BST) Message-ID: <50100C84.3020505@lsces.co.uk> Date: Wed, 25 Jul 2012 16:11:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10 MIME-Version: 1.0 To: PHP internals References: <500EDCC7.1020402@ajf.me> <500EE3B9.8010902@ajf.me> <500EEA76.1030407@ajf.me> <5010007A.8060609@lsces .co.uk> <501007A4.9000200@ajf.me> In-Reply-To: <501007A4.9000200@ajf.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0302.500FFD59.011C, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.7.25.141228:17:7.944, ip=81.138.11.136, rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __HAS_FROM, __USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __CT, __CT_TEXT_PLAIN, __CTE, __ANY_URI, __URI_NO_MAILTO, __URI_NO_WWW, __CP_URI_IN_BODY, BODY_ENDS_IN_URL, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.50100C84.013B:SCFSTAT14830815,ss=1,re=-4.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: Re: [PHP-DEV] Re: Generators in PHP From: lester@lsces.co.uk (Lester Caine) Andrew Faulds wrote: >> I top you 20 years with 37 years. I was programming in Algol in 1975 ( at >> Warwick university ). I'm not a programmer, I'm a hardware engineer who has to >> program to make systems work. I added PHP 12 years ago to create web based >> applications to augment c and Pascal based applications. Many of the concepts >> being added make sense only as extensions to the core code, and don't need to >> be forced into general use. Adding tools that have very specialist use should >> be done as options, which we can leave out if we want to. The it needs to be >> justified switching something on by default. I have no objection to 'new >> facilities', but only if I can also switch them off ... >> > Eh, what? "Switch them off"? > > What on earth do you mean? "use noGenerators" and then break tons of third-party > code relying on it? Or do you think you're forced to use them? The third party code would have to justify using them in my book. But as long as I KNOW what a library is using then I have the option simply to avoid it. At the moment how many third party codes are 'strict compliant' and can be used safely with PHP5.4? In my book this is exactly the same problem. For many years all of my PHP5 code played nicely with PHP4 installations even though I never used PHP4. Nowadays you are saying "You can't use this until your ISP updates" - so libraries NEED to manage this or specifically avoid features that are not in general use 'in the wild' ... ISP are only just updating to PHP5.3 since PHP5.4 is not generally available in the core ISP distributions ... It's additions like this that are delaying adoption rather than enhancing it. > I don't understand, sorry. > > A feature's existence doesn't mean you're forced to use it. Did the introduction > of short array syntax force you to use [] instead of array()?! Until one gets thrown into libraries that use 'short array syntax' exclusively and have to work out what the heck is going on. We don't get forced to USE it, but we do get forced to ensure that we understand exactly what it is doing even if we don't and it adds unnecessarily to the library of functions we need to understand :( -- 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