Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62882 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98280 invoked from network); 7 Sep 2012 00:41:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Sep 2012 00:41:51 -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.163 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.163 smtp163.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.163] ([67.192.241.163:59204] helo=smtp163.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7F/C0-03079-FC249405 for ; Thu, 06 Sep 2012 20:41:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6EA468010A; Thu, 6 Sep 2012 20:41:47 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp26.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 6540F80136; Thu, 6 Sep 2012 20:41:46 -0400 (EDT) Message-ID: <504942C9.6050106@sugarcrm.com> Date: Thu, 06 Sep 2012 17:41:45 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Yahav Gindi Bar CC: Mark , "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Why are the PHP namespaces different compared to C++? From: smalyshev@sugarcrm.com (Stas Malyshev) 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