Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68857 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91854 invoked from network); 2 Sep 2013 20:03:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2013 20:03:02 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.123 smtp123.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.123] ([108.166.43.123:36944] helo=smtp123.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E3/5B-29856-3FEE4225 for ; Mon, 02 Sep 2013 16:03:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 558A21A0A4E; Mon, 2 Sep 2013 16:02:56 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id E0B6D1A0A41; Mon, 2 Sep 2013 16:02:55 -0400 (EDT) Message-ID: <5224EEEF.3070204@sugarcrm.com> Date: Mon, 02 Sep 2013 13:02:55 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Anthony Ferrara CC: Nicolas Grekas , "internals@lists.php.net" References: <5220437A.7050008@sugarcrm.com> <5220D212.3010101@sugarcrm.com> <61FCD6C4A31248078FEAD2BA73D7CD44@gmail.com> <7AF31CC1D1554454AC95AE758D23E92E@gmail.com> <52243F6C.7070806@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Function autoloading From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > So the only case this effects is that you can't autoload a function from > the same namespace that you're currently in without explicitly using > that function. > > That's not such a huge issue. I think it is such a huge issue, because this means this functionality can not be used for reliably loading namespaced functions without prior declaration, and this is pretty much the use case we've been preached about all along. So if it doesn't work in this case without prior declarations just for it, than how it's better than require? > But "fixing" that would be such a massive BC break... There's nothing to "fix", it was a conscious decision about how namespaces must work. Alternative is doing \strlen each time you need string length, which would be just silly. > You would only need to explicitly `use function` those in your current > namespace. Any outside (relative or absolute calls) would still work fine. It's not "only" - functions in current namespace are exactly those I'm likely to use. > And after all, this is the exact reason we implemented `use function`. > Because namespaces WERE useless for functions until last week. Now we > have the power to be explicit with our calls. I don't think RFC proposed well before this issue was raised was actually meant only to fix broken function autoloading proposal. I sincerely hope it has more uses than that, otherwise it's a pretty big mistake. > That's how functions (and namespaces) have always worked. Give it a > try: http://3v4l.org/S6FN8 Keep in mind, functions have been treated as No it's not how it worked - function resolution rules were always "try namespace, then global", unless alias is explicitly specified by use (aliased name is treated as fully qualified, because this is what the function of aliasing is). Just try to remove "use" statement and see. > The big difference is that last time there was no mechanism to be > explicit with what you wanted your code to do without fully qualifying > every call. Today we have `use function`. Which is the same specification, just at the beginning of the file. I'd rather do one require then ten use functions. My opinion is producing autoloader that is inconsistent with how language itself treats import would only produce more WTFs and more people thinking nothing in PHP makes sense and nobody cares about internal consistency of the language. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227