Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41696
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: internals@lists.php.net
Message-ID: <A4F5DBE2-7F83-4C24-8B7D-8D9C9CCE8552@pooteeweet.org>
To: Ryan Panning <rpanning@gmail.com>
In-Reply-To: <5C.FA.15458.9A980194@pb1.pair.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 5 Nov 2008 22:32:52 +0100
References: <29.7A.15458.C4880194@pb1.pair.com> <5C.FA.15458.9A980194@pb1.pair.com>
Subject: Re: [PHP-DEV] Re: Namespace Resolution
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 04.11.2008, at 18:43, Ryan Panning wrote:

> Just to make my post clear, I'm in favor of this approach for non- 
> qualified calls in a namespace.
>
> 1. global
> 2. autoload
> 3. fail


A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just  
chatting on IRC and we all favor the following:

1) ns 2) autoload (for classes) and global (for functions/constants)  
3) fail

So no fallback to the global namespace for classes, but fallback for  
all functions/constants (regardless of internal or not)

Here are some reasons why we do not want a fallback for classes:
- there are far less (and will likely be) global classes compared to  
functions, also class names need to be typed less often than functions  
to begin with => its less of an issue for classes
- more importantly Stas pointed out that "if we don't do it without  
fallback, THEN we'd have problems with typehints, since then we would  
have to start autoloading stuff i.e. fallback would force autoloading  
in some cases where presently there's none (instanceof, typehint, etc.)"

Here are some reasons why we felt that functions/constants should  
fallback:
- most namespace users will be using classes and not functions
- people expect direct access to the vast number of php functions/ 
constants

Here is the reason why we felt we should not limit this to internal  
functions only:
- <@Derick> some people provide drop in libraries for extensions such  
as curl
- at the same time some people might choose to implement frequently  
used global functions inside an extension, which would result in a  
change of behavior (though this is not such a big deal)

Here is a reason why we would limit this to international functions  
only:
- <@Stas> but note that global user-space fallback for function means  
run-time resolution (which may be ok, but slower - no caching  
resolution in bytecode cache)

However given that we expect the fallback to mainly be used for  
situations where one wants to provide a user land fallback  
implementation of something that would usually be available as an  
extension, it seems obvious that this is not the ideal case for  
performance to begin with, and the sole reason is to be able to run  
even in the absence of the ideal situation for performance where the  
function would be provided via an extension.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org