Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41672
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Wed, 5 Nov 2008 00:12:25 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1652368155.20081105001225@marcus-boerger.de>
To: Gregory Beaver <greg@chiaraquartet.net>
CC: Christian Schneider <cschneid@cschneid.com>, 
	Lukas Kahwe Smith <mls@pooteeweet.org>, 
	PHP Development <internals@lists.php.net>
In-Reply-To: <49107527.7060604@chiaraquartet.net>
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>  <F8253A8C-C6EA-4E3C-83AD-C39B1E9E685C@pooteeweet.org>  <4906405F.7090205@zend.com> <deae35790810271859w2d727280m6b46b473a941b00f@mail.gmail.com> <490747B2.2010201@zend.com> <4D9A8597-EFE6-418A-B7F6-EAD9ED2361A5@pooteeweet.org> <7FA6946B-57B9-4BC0-B2F1-AFD47572F363@pooteeweet.org> <491071EC.7020501@cschneid.com> <49107527.7060604@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] namespace separator and whining
From: helly@php.net (Marcus Boerger)

Hello Gregory,

Tuesday, November 4, 2008, 5:15:35 PM, you wrote:

> Christian Schneider wrote:
>> Lukas Kahwe Smith wrote:
>>> one could also do
>>> 1) ns
>>> 2) global
>>> 3) autoload
>> 
>> I'm in favour of this (if it avoids performance problems) as I don't see
>> a problem with giving global priority over autoload.

> Hi,

> This is the current name resolution.  The problem is that:

> <?php
> namespace foo;
> $a = new Exception();
?>>

> will instantiate foo::Exception only if the class already exists, but
> will instantiate Exception otherwise.  This defeats autoload's purpose
> for existing.  We've been over this before.  It's dangerous.

> There is one essential difference between classes and
> functions/constants: autoload.

> The only time the question of load order and fallback becomes and issue
> is when code is not explicitly loaded.  In other words, a developer who
> is relying upon an external function will do this at some point before
> calling the function:

> <?php
> include 'path/to/code/containing/function/source.php';
?>>

> In other words, PHP expects you to actually load the source of functions
> or constants you're going to be using in advance of using it.

> This, I believe, is a reasonable expectation.

> Classes, however, do *not* share this same expectation, because
> autoload's explicit purpose is to allow using classes *before* their
> source has been loaded.

> In other words, it is perfectly all right to have a different name
> resolution for classes than we have for functions and constants because
> of this different expectation.  It is dangerous to fallback for classes
> prior to autoload, but it is not at all dangerous for
> functions/constants because the expectation is different.

> For this reason, the only resolution that we should be considering is:

> classes:
> 1) try ns::class
> 2) autoload ns::class
> 3) fail

Since we can stack autoload we could provide a c-level autoload function
that does the default lookup.

function global_autoload($name) {
  if (($p = strrpos($name, '\\')) !== false) {
    $name = substr($name, $p);
    if (__NAMESPACE__ == substr($name, 0, $p -1) && class_exists("\\$name")) {
      use "\\$name";    // if we find a way to do this at C-levle
    }
  }
}

> functions/constants:
> 1) try ns::function/ns::const
> 2) try internal function/const
> 3) fail.

> Note that I say "try internal" because the only purpose behind allowing
> this is to make it easier to use PHP's built-in functionality.  Any
> userspace stuff should be specifically \prefixed or imported via use.
> And (yes) we need import for functions.

> Greg

> P.S. my mail server has been down for almost a week, apologies to anyone
> who is wondering why I haven't replied to your message, I probably
> didn't get it.




Best regards,
 Marcus