Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64857 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8838 invoked from network); 11 Jan 2013 09:44:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jan 2013 09:44:32 -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 213.123.20.127 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 213.123.20.127 c2bthomr09.btconnect.com Received: from [213.123.20.127] ([213.123.20.127:54082] helo=mail.btconnect.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6C/F9-02684-AFEDFE05 for ; Fri, 11 Jan 2013 04:44:28 -0500 Received: from host81-138-11-136.in-addr.btopenworld.com (EHLO _10.0.0.5_) ([81.138.11.136]) by c2bthomr09.btconnect.com with ESMTP id KMN67975; Fri, 11 Jan 2013 09:44:24 +0000 (GMT) Message-ID: <50EFDEF7.4070408@lsces.co.uk> Date: Fri, 11 Jan 2013 09:44:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14 MIME-Version: 1.0 To: internals@lists.php.net Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.50EFDEF7.0085, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2013.1.11.90017:17:7.944, ip=81.138.11.136, rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __HAS_FROM, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __TO_NO_NAME, __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=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.50EFDEF8.0043: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: PHP is not ... From: lester@lsces.co.uk (Lester Caine) Some of you will have heard this before, but please bare with me ... A number of years ago I needed a new infrastructure to produce 'web based' versions of the windows client code I've been writing since window 3.1 days. I'd been using C++ for many years and still have to support that code. C# and other esoteric 'modern' offerings were being pushed at that time. Some have taken off and some have proven less popular. I started playing with PHP just before PHP5 became RC stage and was very pleased with what I found. An OO 'style' of working that allowed me to escape the straight jacket that the BCB6 object methods enforced and easy learning curve from what I was used to. Since that time e_strict rules have been 'applied' and while I accept some of the logic of those rules, having to create multiple functions to get 'around' the static/object restrictions was starting to create the bloat I'd lost initially. Currently being able to check if an array or a simple variable has been passed gets around the problems I had with BCB6 needing to create separate function wrappers for each parameter type, so discussions on 'improving' this area irritate. Being able to access object variables directly was a big plus so all of the 'magic' to hide them again is annoying. Debugging library code I've been using for years is becoming more and more difficult due to the 'extra' material that is appearing, and I have no doubt that adding 'annotations' into that code will further reduce productivity :( *I* have no control over that, it will happen simply because that seems to be the way people think PHP should go? 'You don't have to use them' is rolled out all the time, but as others have said, unless you don't use ANY third party code that is simply not practical! If I'd wanted C# 10 years ago I could have used it. I found PHP was perfect but it's becoming a case nowadays when I seriously have to consider how I go forward. I have to use Python and Ruby with all of their idiosyncrasies along with fixing bugs in Java to keep my development tools working, so all this talk about 'modernising' PHP is like a sword in the side. Surely I'm not alone in wanting to keep PHP as the simply development platform it had always been and 'improving' things like unicode support and performance? I keep thinking that 'e_simple' is the way to go and disable all of the 'complicated' stuff and - yes - get back to the good old days ... -- 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