Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39937 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98848 invoked from network); 13 Aug 2008 22:25:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Aug 2008 22:25:50 -0000 Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 88.198.8.16 bigtime.backendmedia.com Linux 2.6 Received: from [88.198.8.16] ([88.198.8.16:46064] helo=bigtime.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4A/07-63398-D6F53A84 for ; Wed, 13 Aug 2008 18:25:50 -0400 Received: from localhost (unknown [127.0.0.1]) by bigtime.backendmedia.com (Postfix) with ESMTP id 942BA4144009; Wed, 13 Aug 2008 22:27:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at backendmedia.com Received: from bigtime.backendmedia.com ([127.0.0.1]) by localhost (bigtime.backendmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjxjK2QmfZTH; Thu, 14 Aug 2008 00:27:36 +0200 (CEST) Received: from [192.168.0.151] (77-57-23-243.dclient.hispeed.ch [77.57.23.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mls@pooteeweet.org) by bigtime.backendmedia.com (Postfix) with ESMTP id F073F4144006; Thu, 14 Aug 2008 00:27:35 +0200 (CEST) Cc: Stanislav Malyshev , Marcus Boerger , internals@lists.php.net Message-ID: To: Lukas Kahwe Smith In-Reply-To: <0D64C8C4-2136-4D6B-9EBD-B5956C3044FC@pooteeweet.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 14 Aug 2008 00:23:46 +0200 References: <909776579.20080803142659@marcus-boerger.de> <840985F2-A701-4BE4-91F6-F6B39048CF9B@pooteeweet.org> <48A09FF4.1030101@zend.com> <7f3ed2c30808111411t51553771j389f05c3436bc625@mail.gmail.com> <48A0C415.9090104@zend.com> <48A0D579.2000000@zend.com> <48A0DBAE.2010401@zend.com> <496879481.20080812153636@marcus-boerger.de> <279600845.20080812225135@marcus-boerger.de> <1218621323.4926.1.camel@localhost> <1341995942.20080813152134@marcus-boerger.de> <1218634532.4926.5.camel@localhost> <1714092517.20080813194342@marcus-boerger.de> <48A32817.4020105@zend.com> <10910129111.20080813213721@marcus-boerger.de> <48A33D86.1010806@zend.com> <59637275.20080813221213@marcus-boerger.de> <48A34180.8070601@zend.com> <0D64C8C4-2136-4D6B-9EBD-B5956C3044FC@pooteeweet.org> X-Mailer: Apple Mail (2.928.1) Subject: Re: [PHP-DEV] Inconsistencies in 5.3 From: mls@pooteeweet.org (Lukas Kahwe Smith) On 14.08.2008, at 00:09, Lukas Kahwe Smith wrote: > > On 13.08.2008, at 22:18, Stanislav Malyshev wrote: > >> Simply include a script from two locations with different >> namespaces or one >>> >>> with namespace and the otherone without. >> >> I'm afraid you misunderstand how namespaces work. As I explained >> numerous times, namespaces are file-local, and this when including >> file, it does not matter a bit what was including context. > > I think Marcus is talking about files that are included that do not > specify a namespace explicitly. In this situation the context does > matter. > > We do not know if the developer in question is aware that the > context would matter in this case. Actually like I said in a > previous email it would be nice to at least not throw a warning if > the file that is included specifies an explicit namespace (I assume > that is possible?). Maybe adding a new "include" is a solution. This > way developers can say explicitly what they want to do without > having to suppress the warning. Then again quickly some smartass > developer is going to teach people that these annoying warnings go > away if you just use this new include everywhere. Then again, I am > not sure if I even have my head wrapped around this entire namespace > thing. So one more thing. If people either explicitly require all their files up front or make use of a properly designed autoload scheme, they will side step this problem. So maybe the solution indeed is to have this warning with a link to guidelines on how to do this properly. With explicit "upfront" requires and autoload, there is no need to have includes inside classes, except for the scenario of a template engine. Not sure about that one .. regards, Lukas Kahwe Smith mls@pooteeweet.org