Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:41640 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25739 invoked from network); 4 Nov 2008 15:34:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Nov 2008 15:34:08 -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:44524] helo=bigtime.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E5/32-15458-E6B60194 for ; Tue, 04 Nov 2008 10:34:07 -0500 Received: from localhost (unknown [127.0.0.1]) by bigtime.backendmedia.com (Postfix) with ESMTP id 70DA14144058 for ; Tue, 4 Nov 2008 15:34:51 +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 71UMNdjPn3yg for ; Tue, 4 Nov 2008 16:34:50 +0100 (CET) Received: from [192.168.4.130] (cust.static.84-253-51-151.cybernet.ch [84.253.51.151]) (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 DA5BD4144009 for ; Tue, 4 Nov 2008 16:34:49 +0100 (CET) Message-ID: <7FA6946B-57B9-4BC0-B2F1-AFD47572F363@pooteeweet.org> To: PHP Development In-Reply-To: <4D9A8597-EFE6-418A-B7F6-EAD9ED2361A5@pooteeweet.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 4 Nov 2008 16:32:58 +0100 References: <49048EC1.9060908@chiaraquartet.net> <49061E01.8060503@zend.com> <11c607a60810271344i1a8cf53fl149447ad2f687f99@mail.gmail.com> <490628DB.9060209@zend.com> <11c607a60810271422l68949427pe31786275b0b152c@mail.gmail.com> <08747094-6B50-4A0D-9057-DFD12108B6C6@caedmon.net> <94CCB864-179A-48DA-A89A-3859796A9257@pooteeweet.org> <49063A1D.7070804@zend.com> <4906405F.7090205@zend.com> <490747B2.2010201@zend.com> <4D9A8597-EFE6-418A-B7F6-EAD9ED2361A5@pooteeweet.org> X-Mailer: Apple Mail (2.929.2) Subject: Re: [PHP-DEV] namespace separator and whining From: mls@pooteeweet.org (Lukas Kahwe Smith) On 31.10.2008, at 19:02, Lukas Kahwe Smith wrote: > Hi > > I have tried to collect the various opinions on resolution order > into a single RFC: > http://wiki.php.net/rfc/namespaceresolution > > Proactive damage control: > I have also included some discussion on how the removable of > function/constants would affect the question of namespace resolution > order choices. Lets not use this to get back on to the topic of the > namespace separator and instead focus on the namespace resolution > for now. First lets get an RFC that documents all approaches for > namespace resolution in perfect shape. Divide and conquer. > > Furthermore, we have all noticed that the participation on the list > has increased a lot in the recent weeks. As a result I ask everybody > to restrain themselves a bit more. Try to not reply on an impulse, > maybe wait a few hours before posting. This way we might reduce > redundant replies, also the quality of posts will hopefully be > higher so less misconceptions will need to be cleared later (and > misconceptions have a way to spiral into flamewars). Some people have told me that they found the RFC hard to read. Unfortunately this is not the first time that I have gotten feedback like this from an RFC/FAQ I have written. If anyone has some suggestions for improvements please let me know. I have also just added another approach to the RFC. Instead of loading classes as follows: 1) ns 2) autoload 3) global one could also do 1) ns 2) global 3) autoload this would prevent the issue with performance that Stas pointed out. it would also retain the concept that autoload is a last resort attempt (i guess some people even define classes in the fly if they cannot be found elsewhere to be able to handle errors or even download code when needed). this would obviously mean that when someone wants to intentionally overload a class, its important to either use the fully qualified name or ensure that the class definition is loaded before use (similar situation as we have with functions/constants if we do have the fallback). regards, Lukas Kahwe Smith mls@pooteeweet.org