Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62890 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11846 invoked from network); 7 Sep 2012 02:02:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Sep 2012 02:02:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=ekneuss@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ekneuss@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender) X-PHP-List-Original-Sender: ekneuss@gmail.com X-Host-Fingerprint: 209.85.160.42 mail-pb0-f42.google.com Received: from [209.85.160.42] ([209.85.160.42:57361] helo=mail-pb0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E4/30-09664-B9559405 for ; Thu, 06 Sep 2012 22:02:04 -0400 Received: by pbbrp8 with SMTP id rp8so3476992pbb.29 for ; Thu, 06 Sep 2012 19:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=+uEQGVjWf8qKstg3e0uAnXW7ilapOpFAKEJRGSFvMV8=; b=xc74R34umSsEfpM2l+FLoPjjX5GohehBt08UnPk+LkeySDS5YJ05VFzrneA+RZ+gDd JLdpQoR4u43aYOt8F77epY+xvaS7E0teptzqWOYQYPf73Oa8KFIjex0xPv18hyn7+tcm QuU86CLg4e36dnqAsvD9MHbJIn+HNIgtd8J0WihT8/zxW3v6tfpgHvnHrZSR12enVg99 Sc16MhDYgJJXBEurwVNJ4biI7tXubSgspGUrlYhH+feaEQXSC/wwFGT615G/O9Z68Kmz JbCgVfmuk9Bq9Kp8FmjCFE6etz4V96Ye4wp7RWfYqz+E/Dc4VGCH2bbBsEFlqfnPVGiJ MJGw== Received: by 10.68.220.104 with SMTP id pv8mr7645098pbc.119.1346983320042; Thu, 06 Sep 2012 19:02:00 -0700 (PDT) MIME-Version: 1.0 Sender: ekneuss@gmail.com Received: by 10.68.196.134 with HTTP; Thu, 6 Sep 2012 19:01:38 -0700 (PDT) In-Reply-To: References: <504942C9.6050106@sugarcrm.com> Date: Fri, 7 Sep 2012 04:01:38 +0200 X-Google-Sender-Auth: vVKz6g58qrkSrtqt3Uk96jifdLo Message-ID: To: Yahav Gindi Bar Cc: Stas Malyshev , Mark , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Why are the PHP namespaces different compared to C++? From: colder@php.net (Etienne Kneuss) Hi, On Fri, Sep 7, 2012 at 2:49 AM, Yahav Gindi Bar wrote: > On Fri, Sep 7, 2012 at 3:41 AM, Stas Malyshev wrote: > >> Hi! >> >> > How about adding ability to import the entire namespace? >> >> This option was explicitly excluded because this defeats the whole idea >> of having namespaces - i.e. having names to live in different spaces - >> by explicitly bringing unknown set of names into global space. If you >> allow global import, then you do not know which any of the names comes >> from - it can come from any of the set of imported namespaces, or be >> just global - and you have absolutely no idea about it and no way to >> avoid conflicts. And all that to save you three keystrokes so you could >> write DbConnection and not Db\DbConnection? Definitely not a good idea. >> Current implementation makes it clear where things come from and avoids >> naming conflicts, while still allowing you to use short names instead of >> long and painful ones. >> -- >> Stanislav Malyshev, Software Architect >> SugarCRM: http://www.sugarcrm.com/ >> (408)454-6900 ext. 227 >> > > That's true, but we do got the ability to import only one class from given > namespace and classes aliasing so we can, for example, do something like: > > namespaceClasses.php > > namespace MyNamespace; > class Foo { } > class Bar { } > class Baz { } > > use \MyNamespace\* { > Foo as F > Bar as B > }; > > Then - the Foo and Bar classes will be F and B while Baz and any other > class remain Baz. > I do understand the point of conflicts, but I think that we should give the > programmer the ability to decide whether to import specific class or the > entire namespace. > > Other option I've thought of is to declare rules for importing as keywords > or even a function that can import the namespace with given conflict rules > > for example > > use \MyNamespace\* noconflict; > > or even > import_namespace('\MyNamespace', NS_AVOID_CONFICT); > > or something like that, though I think that a keyword allocated only to > that propose is definitely not good approach... The reason why this is not implemented is simple, and it's not to avoid hard-to-read code or "by design". It is a purely technical limitation of the way PHP handles classes/namespaces: When importing a namespace, PHP may have no idea of the classes contained in that namespace. So when you do use Foo\Bar as Gee; PHP have no idea what Foo\Bee really is, whether it is a namespace itself or a class. Nothing might be loaded at that time. *All* it knows is that it needs to substitute occurrences of "Gee" with "Foo\Bar", that's it. Now of course, this wouldn't work with wildcard imports, because if you do: use Foo\*; use Bar\*; new Plop; Even though Plop might only be contained in one of those namespaces, PHP does not necessarily know, and it doesn't know whether to try \Plop, Foo\Plop, or Bar\Plop. This problem is of course non-existent in other languages supporting wildcard imports, because the set of imported classes is finite and well known, which means that conflicts can be detected right away. Best, -- Etienne Kneuss