Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain horde.org designates 66.92.78.250 as permitted sender)
Message-ID: <20071019232604.201461xbgzwes1n0@technest.org>
Date: Fri, 19 Oct 2007 23:26:04 -0400
To: Gregory Beaver <greg@chiaraquartet.net>
Cc: internals@lists.php.net
References: <20071019224202.20245u5zry52h5c8@technest.org>
	<47196F1A.80400@chiaraquartet.net>
In-Reply-To: <47196F1A.80400@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs)
Subject: Re: [PHP-DEV] Re: Order of class resolution with namespaces and
	autoload
From: chuck@horde.org (Chuck Hagenbuch)

Quoting Gregory Beaver <greg@chiaraquartet.net>:

> Are you suggesting there be namespace-specific autoload?  This sounds
> interesting to me, but also quite complex, not sure the benefits would
> outweigh the difficulties for implementation.  For instance, PEAR2
> namespace would be different from PEAR2::Someclass, and one would need
> to register the same autoload handler for each possible namespace,
> otherwise the class resolution code would have to grep through each
> classname to find sub-namespaces, which is most likely an unacceptable
> performance hog.

Yes, I agree, that sounds awful. :) I was thinking in terms of a =20
duality - say, A::B::C::Exception vs. ::Exception - but when you throw =20
in the possibility that A::B::Exception exists, it sure gets ugly.

>> Otherwise if you are re-defining a global class, which I imagine will be
>> quite common with Exception at least, you will have to explicitly load
>> your Exception classes or they'll never be used.
>
> There is another alternative:
>
> <?php
> namespace Test;
> // explicitly tell PHP that we want Test::Exception to be autoloaded (in
> essence)
> import Test::Exception;
>
> class Tester {
>     public function fail() {
>         throw new Exception();
>     }
> }
> ?>
>
> This calls autoload, as expected, and works wonderfully.  It is also
> quite efficient, but at the expensive of intuitiveness.  However, it
> also has the benefit of explicitly declaring external classes at the top
> of the file, which is a big plus for maintainability when others are
> looking at your code.

Yes, this works. And I'll readily admit that I don't have a better =20
idea right now. An observation, though: when combined with autoload =20
this can change import from only affecting a single file to affecting =20
all subsequent files.

1.php
<?

namespace Test;
import Test::Exception;

throw new Exception();

?>

2.php

<?

namespace Test;

throw new Exception();

?>


If I define a Test::Exception class and include those files in any =20
order, both will create Test::Exception objects regardless of the =20
import statement. However, if I set up autoload, then things become =20
order-dependent:

- If I include 1.php, then 2.php, both files throw Test::Exception
- If I include 2.php, then 1.php, I get an Exception and then a =20
Test::Exception


I can live with this, but I wonder if taking a bit of magic away from =20
nested namespaces would be better. What's wrong with:

- If you are inside a namespace, all classnames that do not include a =20
namespace separator (::) refer to classes of the current namespace.

So, if I want a "global" exception, I use ::Exception. If I say =20
Exception, then I mean my namespace's Exception with no fallback. And =20
if I want another namespace's Exception, I import it (import =20
Other::Exception).

-chuck