Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65606 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65650 invoked from network); 4 Feb 2013 06:18:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2013 06:18:22 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.29 out5-smtp.messagingengine.com Received: from [66.111.4.29] ([66.111.4.29:53064] helo=out5-smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E2/81-55736-BA25F015 for ; Mon, 04 Feb 2013 01:18:20 -0500 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 61A3520968 for ; Mon, 4 Feb 2013 01:18:17 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 04 Feb 2013 01:18:17 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=J8BR6wexdFAN+tbpweyDjz jFCTg=; b=Jplpz5vXdg5u8MzfBZyDdPRJ1Zzt4gjK/YIKRXobYkpplX63D0pTlB TUC/6ZCBlEtawD1K0zd1S4niZLAAHU7MijywzJjXVbC9ExkVvhOJEMY6UI6ULaWp TI2WeHrdtnN63yHJ21Z42/85RR5cua/oQbIUvvjqfh29nZc6OUju4= X-Sasl-enc: bRHYFBuliqBvfRlvBoKapfCTfwiETpllHgu2zdKCtcbd 1359958697 Received: from [192.168.42.21] (unknown [98.220.238.115]) by mail.messagingengine.com (Postfix) with ESMTPA id 17AA94827C2 for ; Mon, 4 Feb 2013 01:18:17 -0500 (EST) Message-ID: <510F529F.9080405@garfieldtech.com> Date: Mon, 04 Feb 2013 00:18:07 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: internals@lists.php.net References: <5FC22A05-FE01-4222-892C-773ECC39E471@gmail.com> In-Reply-To: <5FC22A05-FE01-4222-892C-773ECC39E471@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Questioning the future of PHP From: larry@garfieldtech.com (Larry Garfield) On 02/03/2013 08:51 PM, Matt Wilson wrote: > Hello all. I'd like to start by saying that I am by no means an expert on the subject at hand, and my knowledge is limited to pretty much basic C/C++. I have done little more than patch and write ad hoc extensions for PHP in the past. I'm not looking to criticize so much, as I'm just interested in an honest discussion, for my own sake and understanding. > > Many years ago I was on this internals list lamenting that PHP lacked namespaces. I was passionate in my conviction that it couldn't be a true language if it lacked them. But it wasn't until they were finally being considered that I realized the one weakness in PHP that prevented a proper namespace system. The autoload problem. Since PHP lacks an inherent style of code importation, it is a decision largely left up to the developer. This of course causes an order of precedence problem. > > Now, I won't lie, some of my beef with namespaces as they stand is the \. What can I say, I like a certain feng shui in my code. I understand the technical limitations (or at least think I do) and the problem of ambiguity with other operators, however I feel more effort might have been made. > > If I were to pull some examples out of my ass, and feel free to rebuke me if I'm missing something obvious, > > [namespace foo.bar] > > new [foo.bar.SomeClass]() > > Would that be so hard to distinguish in the parser? If it is, I'd be grateful to know why. Maybe it would work, maybe it wouldn't, I don't know. But that ship sailed a long time ago and it cannot be changed now without breaking a few million lines of code. Please let that issue die. > Touching back on what I mentioned earlier about PHP not having an inherent way to load files, and in daily use it's somewhat arbitrary. I share the philosophy that the programmer should tell the code what to do, and not the other way around; however, I think some enforced structure can be good. This is something of a wet dream of mine and one I highly doubt will come true, but to get rid of __autoload (or at least supplant it with a default loader) would be a dream. I think it's something that PHP needs, to complete some one of advances its made in recent years. > > Thanks, > Matt "The autoload problem" has already been solved by PSR-0. If you're not using it yet, you should. All the cool kids are. http://www.php-fig.org/ If you're using Composer to manage dependencies, it includes a fully capable PSR-0 autoloader that "just works", as well as a classmap-based option. If you're not using it yet, you should. All the cool kids are. http://getcomposer.org/ --Larry Garfield