Re: merging Controversial changes back into PEAR2 Standards
| From: | Gregory Beaver | Date: | Sun, 23 Sep 2007 22:53:29 +0000 |
| Subject: | Re: merging Controversial changes back into PEAR2 Standards | ||
| References: | 1 2 3 4 5 6 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-48139@lists.php.net to get a copy of this message | ||
Travis Swicegood wrote:
> How will the shortened version display errors? As the aliased code, or
> as the original? If it's the aliased code that would obfuscate the
> code, no?
<?php
import Blah::Blah;
$a = new Blah;
?>
yields:
Fatal error: Class 'Blah::Blah' not found in
/home/cellog/workspace/php6/test.php on line 3
>> PEAR2_Pyrus_PackageFile_v2Iterator_FileInstallationFilter::setParent($this);
>>
>>
>
> Pulling one line out of context :-)
>
> At this point, would you be working with the
> PEAR2::Pryus::PackageFile::v2Iterator namespace for that code? If so,
No, it would be PEAR2::Pyrus::PackageFile namespace, in class v2.
> Back on topic, do imports happen in a file scope, or the current scope?
namespaces declarations and imports are strictly per-file. Otherwise
this code:
file.php:
<?php
class bar {}
?>
file1.php:
<?php
namespace Boo;
include 'file.php';
?>
would result in the "bar" class either being ::bar or ::Boo::bar
depending on the order of file inclusion.
> Another issue assuming imports are file level, how will phar handle
> imports? My understanding, though it may be wrong, is that phar pulls
import is unaffected by anything, it is not file-conscious except that
it only applies to the file that it is within. As far as PHP is
concerned, Phar files are identical to filesystem files.
I had proposed renaming "import" to "alias" but this was thrown out :).
PHP namespaces are designed solely to solve the problem of conflicting
classnames and of long class names. As such, import does not actually
load any code, "import X as Y;" only tells the PHP interpreter "when you
see X, pretend it was actually Y" and only until the end of the current
file. However, import is all-powerful. You can, for instance, choose
to import internal classes under new names and then redeclare them, as in:
<?php
namespace Mine;
import Exception as X;
class Exception extends X
{
}
?>
What import really does is make fatal errors clearer. For instance:
<?php
$a = new Mine;
?>
Fatal error: Class 'Mine' not found in
/home/cellog/workspace/php6/test.php on line 2
Compare to:
<?php
import PEAR2::Mine;
$a = new Mine;
?>
Fatal error: Class 'PEAR2::Mine' not found in
/home/cellog/workspace/php6/test.php on line 3
Also, this code simply doesn't work (and looks weird):
<?php
namespace Oops;
class Exception extends Exception
{
}
?>
But the above example, importing the internal Exception class, seals the
deal.
Greg