Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54654 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63893 invoked from network); 17 Aug 2011 21:44:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Aug 2011 21:44:03 -0000 X-Host-Fingerprint: 96.2.18.191 host-191-18-2-96.midco.net Date: Wed, 17 Aug 2011 17:44:01 -0400 Received: from [96.2.18.191] ([96.2.18.191:29265] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 81/F0-56760-0263C4E4 for ; Wed, 17 Aug 2011 17:44:01 -0400 Message-ID: <81.F0.56760.0263C4E4@pb1.pair.com> To: internals@lists.php.net References: <4E481136.3090508@sugarcrm.com> <4E483284.4010100@googlemail.com> <4E4838E1.3000006@sugarcrm.com> <4E48430D.6070409@googlemail.com> <4E486A50.4010700@sugarcrm.com> <4E48A22E.1040900@googlemail.com> <4E48AD3E.6010801@sugarcrm.com> <4E48C126.50707@sugarcrm.com> <4E48D848.1070407@sugarcrm.com> User-Agent: slrn/pre1.0.0-18 (Linux) X-Posted-By: 96.2.18.191 Subject: Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload* From: weierophinney@php.net (Matthew Weier O'Phinney) On 2011-08-17, Michael Morris wrote: > --001636833a84f3029304aab9fd15 > Content-Type: text/plain; charset=ISO-8859-1 > > This member of the peanut gallery would like to point out the following > danger. Consider the following function collection for namespace A. > > namespace A; > function strpos() {} > function myfunc() {} > > Now if I understand the RFC correctly there's an unintuitive problem as > follows - if myfunc is called first, strpos gets redefined for that > namespace and functions as the author might expect for the namespace. If > strpos gets called first then it will behave as it does in the global > namespace, which may or may not be desirable. In any event, from where I > stand here in userland, this is potentially confusing. I'm an amateur of > the 1st degree, but my gut tells me that the behavior state of any given > function should NOT be determined by whether or not a different function was > invoked before it. There's nothing saying you can't have the exact same situation right now with classes and autoloading, too. Example: namespace A; class ReflectionClass { /* ... */ } class MyClass { /* ... */ } What if you have an autoloader that, on encountering A\MyClass then loads that file? You've now redefined ReflectionClass for the A namespace. The main difference, of course, is that if ReflectionClass is not explicitly imported, PHP will barf and tell you it doesn't know about A\ReflectionClass. While I understand your objections, I think that after the functionality exists, there can be discussions about best practices -- e.g., putting one function per file when autoloading, or documenting when all functions for a given namespace will be in a single file. It's really a matter of the project educating its users -- I don't think it should be a blocker for implementing it at the language level, though. > On Mon, Aug 15, 2011 at 5:49 PM, Chris Stockton >wrote: > >> Hello Stas, >> >> On Mon, Aug 15, 2011 at 1:26 AM, Stas Malyshev >> wrote: >> > Hi! >> > It's not a shortcoming, it was designed that way, and for very serious >> > reasons. If you want to know the reasons, there were discussed >> extensively >> > when namespaces were discussed. Please re-read that discussion. And all >> > things you propose now were already discussed back then too. If you hope >> > people would write \strlen instead of strlen, this discussion is >> pointless >> > because it won't happen. >> > -- >> >> I see your viewpoint from a architectural/design perspective and they >> are valid, but I think the impact and design could be lightened with >> some simple rules of precedence. >> >> I think it would be fair to say, autoloader will not be called on a >> function like strpos, or any builtin compiled extension. Only once >> those are cycled through will autoloader for functions be called. At >> this point the performance penalty doesn't exist, because at this >> point the program execution would have halted with a fatal error >> anyways. >> >> -Chris >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > --001636833a84f3029304aab9fd15-- -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc