Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33939
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error)
Cc: internals@lists.php.net
Message-ID: <7ADAF424-D5CC-48F7-AF4C-4D8BC219C1CA@bitxtender.com>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <475F10DA.6000909@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Tue, 11 Dec 2007 23:57:13 +0100
References: <11970653983080000@9866357972520000.9866341568840000> <475BDDF1.7040605@ctindustries.net> <1723341090.20071210220025@marcus-boerger.de> <1197323296.3922.5.camel@sbarrow-desktop> <00A2E2156BEE8446A81C8881AE117F199A0715@companyweb> <A5519084-2CBA-40F4-BDAB-96036428DB17@bitxtender.com> <475ED038.3080004@zend.com> <7F9E1E02-FF89-474B-9E94-007747B3637A@bitxtender.com> <475EF175.2030304@zend.com> <C0D87144-50B3-4C26-BEDF-E5BB93ED1C4A@bitxtender.com> <475F01B1.8090407@zend.com> <31696FA6-ADC3-4853-A5AE-23FA16750B3D@bitxtender.com> <475F10DA.6000909@zend.com>
Subject: Re: AW: [PHP-DEV] Namespace resolution
From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

Am 11.12.2007 um 23:36 schrieb Stanislav Malyshev:

>> import Name::Space;
>> // only stuff from Name::Space available, no PHP internal stuff
>> import __php__;
>> // now PHP's classes are loaded, too.
>
> So "import php" make internal classes always take priority even when  
> there's a class in this namespace by that name? But you could  
> achiever the same just by avoiding naming classes the same as  
> internal classes, you surely know which classes are in your own  
> namespace? Since in both cases code change is needed, why that one  
> is better? If you created Name::Space::DateTime, surely there was  
> some intent in having it named specifically the same as DateTime  
> class in PHP?

Ah. Now that you mention it, there was a flaw in my logic. The idea  
was not that PHP classes take precedence, but in this case, PHP's  
DateTime class would already be "loaded" so no autoload would be  
attempted for a Name::Space::DateTime. If, however, that  
Name::Space::DateTime was already autoloaded by the time we reach that  
code, things would just break. Hmmh. Jochem pointed it out in the  
other message; I think this autoloading thing is going to be tricky...

> Java package system is very different. For starters, they don't have  
> global space at all. And they have offline compilation stage which  
> verifies all the dependencies.

Yes, sure. I was just saying that other languages also require you to  
import language-internal stuff from time to time.

>> I don't think that PHP's internal stuff needs to be magically  
>> available. We can force developers to explicitly request access to  
>> it.
>
> We can, but we should not. Internal classes are internal for a  
> reason - people use them a lot. Making it hard to access frequently  
> used classes to enable rarely used functionality is not the right  
> way to go.

Okay, but what do we do about the issue described initially then?  
Here's a concrete example to show the problem:

<Name/Space/DateTime.php>
   namespace Name::Space;

   class DateTime {}

<Name/Space/Ship.php>
   namespace Name::Space;

   class Ship {
     public static function __autoload($className) {
       // ... autoloader, can load Name::Space::DateTime
     }
   }

<somestuff.php>
   function someStuffWeDoNotHaveControlOver() {
     $foo = new Name::Space::DateTime();
     // ...
   }

<setup.php>
   require_once('Name/Space/Ship.php');
   spl_autoload_register(array('Name::Space::Ship', '__autoload'));

<example.php>
   require_once('setup.php');
   import Name::Space;
   $d = new DateTime(); // a PHP DateTime
   someStuffWeDoNotHaveControlOver();
   $d = new DateTime(); // a Name::Space::DateTime now!


See what I mean?


David