Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55928 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72186 invoked from network); 24 Oct 2011 16:51:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2011 16:51:44 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.193 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.193 smtp193.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.193] ([67.192.241.193:52365] helo=smtp193.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1F/74-43916-E9795AE4 for ; Mon, 24 Oct 2011 12:51:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id EA7CF3C8387; Mon, 24 Oct 2011 12:51:39 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id A91F53C82F8; Mon, 24 Oct 2011 12:51:39 -0400 (EDT) Message-ID: <4EA5979A.8050307@sugarcrm.com> Date: Mon, 24 Oct 2011 09:51:38 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Willbanks CC: PHP Internals References: <4E208FE7.4020606@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] SplClassLoader From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 10/24/11 9:45 AM, Mike Willbanks wrote: > By standardizing this inside of an extension gains us 2 very major features > (IMO): But we already have the extension, don't we? > From the RFC prospective it does seem like many things are missing: > 1. Examples > * The easiest example being that of a folder structure and class naming such > as in PSR-0 with the instance of the autoloader. > 2. Use Cases > * Examples of framework cases... additionally extending framework libraries > in separate folders. Yes, the RFC is not really up-to-date or complete. Another thing is I wouldn't really want to add anything that isn't a bugfix or BC fix or anything of this nature after RC1 is out. So if there's support for getting it into SPL, proper RFC, consensus gathering, patch, and all the process should be complete by Nov. 10, otherwise it's not in for 5.4.0. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227