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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
