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.

Lukas Kahwe Smith

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to