Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65605 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59563 invoked from network); 4 Feb 2013 05:12:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2013 05:12:40 -0000 Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) Received: from [173.1.104.101] ([173.1.104.101:57685] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/60-55736-6434F015 for ; Mon, 04 Feb 2013 00:12:39 -0500 Received: from localhost ([216.220.114.66]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id PHQ65535 for ; Sun, 03 Feb 2013 21:12:35 -0800 Date: Mon, 4 Feb 2013 00:12:29 -0500 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <717547527.20130204001229@cypressintegrated.com> To: Matt Wilson In-Reply-To: <5FC22A05-FE01-4222-892C-773ECC39E471@gmail.com> References: <5FC22A05-FE01-4222-892C-773ECC39E471@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Questioning the future of PHP From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) > This is something of a wet dream of mine TMI, my friend. TMI. Anyway... I think your Subject is unnecessarily trolly even if the substance of your post isn't. So maybe you could re-post with a "WAS: Questioning..." to avoid p'ing off the dev team? If I'm understanding your statement of "The autoload problem" correctly, the language-default spl_autoload function indeed allows you to install a package safely -- in an environment that you know has not completely overridden the default autoloader. If you want to make sure the default is called for your directory structure, then you can make sure to tell the people using your package to put the default spl_autoload in their autoloader chain. Can you explain how this departs from your vision? I don't think what you want is another "default" autoloader, but a way of ensuring the system default is called once your package is physically installed on a system. Unfortunately, there would always be file I/O overhead if it were to be called even if the PHP install has nothing in the default file layout. You could argue that the default spl_autoload should run unless deliberately turned off (never mind BC for the moment), but then it would just become a popular best practice to turn it off and you're back at the same place. -- Sandy