Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41692
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 74.125.78.26 cause and error)
Message-ID: <4911FE95.1030503@chiaraquartet.net>
Date: Wed, 05 Nov 2008 14:14:13 -0600
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Stanislav Malyshev <stas@zend.com>, Marcus Boerger <helly@php.net>, 
 Christian Schneider <cschneid@cschneid.com>,
 PHP Development <internals@lists.php.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> <1652368155.20081105001225@marcus-boerger.de> <6246E5E0-BD11-48E2-B32B-DA7F82E605E2@pooteeweet.org> <885621138.20081105004925@marcus-boerger.de> <4910E33C.2070609@zend.com> <02297291-ADDF-4AA1-897C-607B93980A32@pooteeweet.org>
In-Reply-To: <02297291-ADDF-4AA1-897C-607B93980A32@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespace separator and whining
From: greg@chiaraquartet.net (Greg Beaver)

Lukas Kahwe Smith wrote:
>
> On 05.11.2008, at 01:05, Stanislav Malyshev wrote:
>
>> Hi!
>>
>>> or in other words give the user the ability to specify when he wants
>>> the
>>> fallback to global and not doing a fallback to global per default.
>>> That way
>>
>> This would be quite complex thing since this way you can't be sure
>> which class gets loaded when you say, e.g., Exception - and thus, if
>> you write something like "throw new Exception("XML did not load")"
>> and except My\XML\Parser\Exception and have catch for it but get just
>> Exception your application would happily unroll to the top and fail.
>>
>> I think actually knowing what class is going to be loaded is a good
>> idea and overriding loader behavior so it's asked for one class and
>> loads completely different one is not a good idea. One would expect
>> if he asks for class X he gets class X, not class Y.
>
> Well, its not like the person is getting Y when he is expecting X.
> Both classes have the same name after all, so there is some relation
> between these two classes. More importantly its the users choice to
> enable this in __autoload(). As all frameworks got that its the end
> users job to implement autoload, I would not worry soo much in this case.
>
> Just a question: How hard would it be to implement in case we do want
> this? 

To do in any kind of performant way would require storing the source
filename along with the class name in the opcode (not hard), and would
also probably best be implemented not just as an autoload callback, but
as code that checks a flag in EG() inside zend_fetch_class.  Thus, when
spl_autoload_register is passed in the dummy resolver name, it would
simply set a flag.  This would also mean we would have to disallow a
chain like so:

<?php
spl_autoload_register('blah');
spl_autoload_register('__internal__'); // or whatever we decide to call it
spl_autoload_register('another');
?>

The last call should throw an error.  __internal__ should either be the
first or the last registered autoload.

Once this is set up, the actual code would simply check for whether the
internal class exists.

Even though it is technically possible, there is one huge flaw in the
idea: autoload can be changed external to the current file.  How do you
safely design code that would work with both autoload implementations? 
The truth is that code designed for internal resolution prior to
autoload would fail with any other resolution order, and code designed
for autoload prior to internal resolution would fail with any other
resolution.

There is only 1 safe and simple way to do this, and that is to have the
same resolution order in all cases, and the only safe resolution is 1)
ns::class 2) autoload ns::class 3) fail

Greg