Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40379
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <48C5A909.4030502@zend.com>
Date: Mon, 08 Sep 2008 15:36:57 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Greg Beaver <greg@chiaraquartet.net>
CC: internals@lists.php.net
References: <48C59D5C.4050507@chiaraquartet.net>
In-Reply-To: <48C59D5C.4050507@chiaraquartet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespace examples (solving name resolution order issues)
From: stas@zend.com (Stanislav Malyshev)

Hi!

First of all, I'd like to thank Greg for moving discussion to the 
constructive way, way of code examples and proposed solutions.

> Currently, in order for this code to be autoload-compatible, we need to
> use all of the classes:
> 
> <?php
> namespace PEAR2::Pyrus::PackageFile::v2Iterator;
> use PEAR2::Pyrus::PackageFile::v2Iterator::File;
> use PEAR2::Pyrus::PackageFile::v2Iterator::FileAttribsFilter;
> use PEAR2::Pyrus::PackageFile::v2Iterator::FileContents;
> ?>

No, you don't. You just need to use namespace::File etc. where 
appropriate. You may do what you did too, but you don't have to.

> performance slowdown can be 100% removed (with identical functionality) via:

So you traded 3 uses for 3 uses. And on top of that - you also traded 
imaginary case of somebody in the future adding internal class named 
File (how probable is that? Quite near 0 - by now nobody would add 
classes with names like that even in core, let alone in extensions) - 
which is easily avoidable by using namespace:: in this particular case 
and can be thus easily fixed if that improbably thing happens - for very 
real case of having to write use for *EVERY* internal class, even if you 
*NEVER* intended to override anything with anything but just using 
namespaces for your own private stuff. You end up paying for imaginary 
case which would never happen in reality with very real busywork - which 
is unavoidable and would with 100% guarantee silently break your 
application if you forget to do it even once.

> Part 4:
> solving the disadvantages of the new approach
> 
> 1) each internal class can be "use ::classname;" to remove this
> performance hit 100% of the time

Not "can", but "must". Effectively, each instance of the code that uses 
internal class without :: or "use ::" is a bug by your approach, since 
it immediately introduces performance-killing slowdown (remember - since 
it's exhaustive search for file that doesn't exist, it may be dozens of 
filesystem accesses without possibility of bytecode cache helping you).

The only logical option there would be to prohibit use of internal 
classes without :: altogether - since there's no situation where it 
isn't a bug. I'm not sure I want to accept that - are you?

> 2) to detect missed classnames, add a new error level, E_DEBUG, which is
> disabled by default and is used to note potentially buggy situations,
> i.e. "XMLReader internal class ambiguity, use ::XMLReader if you intend
> to use internal XMLReader class".  lint could enable E_DEBUG, and this
> is easily implemented at parse time, since all internal classes will be
> loaded.

That's not a solution, since it supposes you have 100% coverage unit 
tests for all your code. I.e. you might add it, and if we eventually fix 
error reporting so that muted errors would be fast it even might not 
hurt you, but it wouldn't make life any better for real application 
where you don't have 100% coverage for every possible code path.
BTW, adding new error level for every new problem doesn't seem smart for 
me - IMHO we have enough levels as it is already.
Having a tool checking it may help, but I don't think it is smart to put 
such a landmine into the language and expect the users to always use 
proper tools to avoid it. I think it would be irresponsible.

> 3) a simple script that detects internal class names in a script and
> adds use statements to the top of the script:

I would hate to have all my code to be peppered with tons of use 
statements each time I use internal class... but maybe it's just my 
opinion. If you allow resolving to internal class only with either "use 
::Exception" or ::Exception, this proposal is non-contradictory, even 
though I like it less than the current state of affairs.

Also note that if we accept that we must deal with functions - either 
have rule for them saying you can use internal function name without :: 
unlike class name (as it is now) - thus having functions and classes 
resolve differently - or have to always use :: for internal functions 
too (which IMHO in PHP case is as close to hell as you can get being a 
programming language). Same for constants. So for this proposal to be 
complete there should be answer for that too.

I'd like to know how many people would like that better than what we 
have now - i.e. having unqualified name without use to always resolve to 
namespace::name (all the rest follows from here automatically).
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com