Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68850 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62358 invoked from network); 2 Sep 2013 12:58:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2013 12:58:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.182 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.128.182 mail-ve0-f182.google.com Received: from [209.85.128.182] ([209.85.128.182:52202] helo=mail-ve0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FB/C6-29856-77B84225 for ; Mon, 02 Sep 2013 08:58:32 -0400 Received: by mail-ve0-f182.google.com with SMTP id m1so3026966ves.41 for ; Mon, 02 Sep 2013 05:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lo2Lp3UOJSbiUhahkm8VMumjeyCu/m7JD5R76oy1wkI=; b=tYv7xjdcomypnaB1LyAWTc/UpbH3MyYzi060UE6Xmy+rPkgeBzWikMi6rhIVoyxD/j J48eJhqPbsGvhHAud6o8P4K42LueCBf/Rl/MTsjYSJRxMwGoUyNkUlfV1WuAAuk5xfBi yvF5/nCsnw+xuQ5SlqwsdbWqgvW5M7AEO7Iy1ul7jwHXJ/bazxkaHl0QcFllequNE+vm sUQE1HpI8YfMvrulT4gXpQrOSLgWnHzdkQbH04qQT3DlZkoHJYWQNWPxXZm5odMLcJ53 45O+8bG8dM4Oc4IzYpCzeN7dtK+/baWqaTyOKzbA2yi4Yybz4VLkO2nMYu7JUp4fMRLO TmFw== MIME-Version: 1.0 X-Received: by 10.52.164.102 with SMTP id yp6mr19442625vdb.14.1378126708886; Mon, 02 Sep 2013 05:58:28 -0700 (PDT) Received: by 10.58.94.201 with HTTP; Mon, 2 Sep 2013 05:58:28 -0700 (PDT) In-Reply-To: <52243F6C.7070806@sugarcrm.com> References: <5220262A.6040702@sugarcrm.com> <5220437A.7050008@sugarcrm.com> <5220D212.3010101@sugarcrm.com> <61FCD6C4A31248078FEAD2BA73D7CD44@gmail.com> <7AF31CC1D1554454AC95AE758D23E92E@gmail.com> <52243F6C.7070806@sugarcrm.com> Date: Mon, 2 Sep 2013 08:58:28 -0400 Message-ID: To: Stas Malyshev Cc: Nicolas Grekas , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a11c2c1eaf0535004e56620b1 Subject: Re: [PHP-DEV] Re: Function autoloading From: ircmaxell@gmail.com (Anthony Ferrara) --001a11c2c1eaf0535004e56620b1 Content-Type: text/plain; charset=ISO-8859-1 Stas, > namespace foo { > > use function biz\buz; > > use foo\bar; > > > > something(); // autoloaded as "something" > > Wait, so it wouldn't work like class autoloader, using fully qualified > name? And autoloader would not then have any information about > namespaces, so you'd have to specify explicit imports or full namespace > names for any namespaced functions you use in your code? > It indeed does work like the class loader in all but one case. When the compiler knows what you're intending (via explicit use, relative or absolute qualification), it can load the namespaced function. The time it is different is when you don't `use function` and just write `foo()`. With classes, this works fine, because there is no "fallback" behavior. With functions, it can't, because it was decided long ago to silently fall back to using a global function if this happens. 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. The bigger issue (for me) is that in 5.3+, you have code that means different things depending on the state of the engine. In the example above, that function call can mean "foo\something" or "something". Having a function call that isn't obviously resolvable is... But "fixing" that would be such a massive BC break... > That doesn't sound very practical. It's much easier to do one require > than to import manually each function in the namespace and requiring to > explicitly name all of them removes half of the usefulness of namespaces > - if you wanted all the full names, you could use > very_long_names_like_this() as before. > You would only need to explicitly `use function` those in your current namespace. Any outside (relative or absolute calls) would still work fine. 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 think we discussed all these problems last time function autoloading > topic came up. > > Also it is weird that namespace name is added to bar\baz() but not to > bar(). This is contrary to how namespaces work in other places - where > namespace name is added to everything not fully quailified. > 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 second class citizens in PHP since 5.3. They haven't played well with namespaces, or autoloading. Today we've fixed half of that issue. This RFC attempts to fix the other half. > > Does that make sense? > > Frankly, for me it doesn't. Now I recall namespaces resolution and > fallbacks was one of the reasons why function autoloading proposal > failed the last time. IMHO this is a pretty big problem for practical > usage of this - as pretty much the only case for function autoloading is > resting on namespaces, so if autoloader can't deal with namespaced > resolution rules, it's not good. 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`. Anthony --001a11c2c1eaf0535004e56620b1--