Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:41484 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23759 invoked from network); 27 Oct 2008 20:44:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Oct 2008 20:44:10 -0000 Authentication-Results: pb1.pair.com header.from=phpwnd@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=phpwnd@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.198.239 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: phpwnd@gmail.com X-Host-Fingerprint: 209.85.198.239 rv-out-0506.google.com Received: from [209.85.198.239] ([209.85.198.239:29509] helo=rv-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 94/5D-34199-91826094 for ; Mon, 27 Oct 2008 15:44:10 -0500 Received: by rv-out-0506.google.com with SMTP id g37so2438687rvb.23 for ; Mon, 27 Oct 2008 13:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=UChXguK6Wd87+nQFhI7+7Gd+nL0FFYSBIVs6jUslkWU=; b=B3j0uqF6gW8gS8XrStFpbiNKMqnfhMzR9/r8Wnd3w7NCRqIZdS8oruREEmt4uAID/o 91R1hmMwETbu/cjRmdowL4kCdYSE3dGTykXJlRYszJfaIE7QxvYhFV8nzhYm69OtRaz/ HUry/zAbJxOwhAU+9lY0IFfsTiYcfY8NVcRYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=AD05aIXhT6e7t5Nh0I11y9o2XgdKNYFuLqa4OaR4r3tHM/g5fNVEYnef7Z3JSRSObU lyh1l0H164zTDUBJxonpEt76EJSS9gYo41SK5lQmRY0fPORFsgXq2mokfE4oXycSWkIo pgztibpeszXsFlNrDT7d/SQfnMwWXGSiK+qDc= Received: by 10.140.249.20 with SMTP id w20mr3515875rvh.21.1225140247227; Mon, 27 Oct 2008 13:44:07 -0700 (PDT) Received: by 10.141.83.21 with HTTP; Mon, 27 Oct 2008 13:44:07 -0700 (PDT) Message-ID: <11c607a60810271344i1a8cf53fl149447ad2f687f99@mail.gmail.com> Date: Mon, 27 Oct 2008 21:44:07 +0100 To: "Stanislav Malyshev" Cc: "Rodrigo Saboya" , internals@lists.php.net In-Reply-To: <49061E01.8060503@zend.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49048EC1.9060908@chiaraquartet.net> <4904CE3B.2000001@chiaraquartet.net> <4905EDA9.9050301@zend.com> <11c607a60810271049y419c252q7e21cde9221f1996@mail.gmail.com> <490600CD.5020207@zend.com> <11c607a60810271252r4bedeea8q59ce5423891d8e59@mail.gmail.com> <49061E01.8060503@zend.com> Subject: Re: [PHP-DEV] namespace separator and whining From: phpwnd@gmail.com ("Josh Davis") 2008/10/27 Stanislav Malyshev : >> Then, if we assume that most people will use the global namespace >> without prefixing it, what would be the best resolution order for >> them? (you didn't mention it in your previous message) > > Using the prefixed names. I'm sorry but I still don't get what's your "right" way to do it. For reference, the "wrong" way is: >> 1) check for namespaced\classname >> 2) try to autoload namespaced\classname >> 3) check for internal classname How would you reorder those? > I consider knowingly putting performance bomb into the language with the > reasoning of "if you know what you are doing, you can disarm it" extremely > bad idea, especially in PHP which is supposed to be low-learning-curve > language. You keep throwing that "performance bomb" thing even though there is no benchmark about it. You are speculating that people will have huge librairies with autoloads that search for files inside the include_path. Is it wise to base the resolution order on those speculations? >> Include + relative path does not give any indication either and it >> does exactly what you've described above (traverse the full include > > Include can be cached. Failed autoload can't. ...but didn't you say "one time is enough"? According to your own logic, include is a "performance bomb" as well. My point is that your base scenario is simply not realistic. Only the biggest websites need to perform without touching the disk. Only some very complicated framework will autoload classes outside of their directory and attempt to traverse the include path for some reason. Those are fringe cases, and all they need to do to perform efficiently is prepend the class names with \ or fix their autoloader. On the other hand, changing the resolution order to prefer internal classes over autoloading induces a loss of functionality that can only be fixed by explicitly including the needed files in advance, defeating the purpose of an autoloader. Anyway, I feel like I've made my point, the discussion isn't progressing and my arguments have already been rehashed in past discussions so I'll probably rest my case. Thanks for reading ;) -JD