I cannot imagine any "valid" use case for this. Autoloading is designated for classes only (that may happen to be  located in a namespace). If you need autoloading functionality for group of functions, put them as static methods  inside an abstract class.

Example:
--------

namespace MyFramework\MVC;

abstract class Dispatching
{
    static public function myFunc() { ... }
    // etc
}

--------

Then you can take advantage of the autoloading.

shiranai7 at hotmail dot com,
why would I use a class if I don't need a class?

Anyway, ways to hack around are well know. The idea here is that we wouldn't need 
to "hack around". Since we have namespaces - it can be done.

lcfsoft at gmail dot com,
You cannot expect anything to be loaded just by an "use" statement. It just defines a local alias for a class or namespace. The classes get loaded only when they are actually used.

Based on your example I think that you are looking for a way to "autoload functions". While it could possibly be handy in your case, I dont think it will ever be an actual feature. It is not even possible to import a function or constant through the "use" statement, so why this?

Using an abstract class is not "hacking around" in this case. Why do you need to do this:

dispatching\dispatch(...);

if you can do this?

dispatching::dispatch(...);

The functionality is IDENTICAL, with added bonus of possible autoloading. Do you really need that \ instead of :: ? That is the only actual difference.

shiranai7 at hotmail dot com,

If your mindset towards this problem was valid we wouldn't need to have 
namespaces 
introduced and implemented in the first place. We would all be fine with those 
Zend_Crypt_Math_BigInteger_Bcmath, because, you see, the functionality is 
IDENTICAL to what 
we have with Zend\Crypt\Math\BigInteger\Bcmath now.

If I need to make an abstract static class's method instead of a function to 
achieve 
something - it's nothing but a hack. It may work, it may work the same way - but 
it's a 
hack.
 So yes, I really do need that "\" instead of "::".

>> You cannot expect anything to be loaded just by an "use" statement. It just 
defines a 
local alias for a class or namespace. The classes get loaded only when they are 
actually 
used.

What you said here, however, is correct. So, yes, it may not be so trivial as 
adding another 
line of code.

But it's important I believe. Why limit PHP developers to classes? If you want 
to know why 
we shouldn't - check out any other decent programming language e.g. Python. 

Yes, autoloading for classes exclusively might work before as we didn't have any 
sort of 
namespaces/packages AT ALL - but now we do and this should be revisited.

lcfsoft at gmail dot com,

>>> Zend_Crypt_Math_BigInteger_Bcmath, because, you see, the functionality is IDENTICAL to what  we have with Zend\Crypt\Math\BigInteger\Bcmath now.

Yes, namespaces were introduced as a better alternative to ugly identifier prefixes. But this has nothing to do with "autoloading functions".

--

My point is that this approach is rather unusual. Bunch of class-less functions defined in a file is like pre-php 5 procedural code. Of course I am in no position to tell anyone what is the correct way to organise their code or even decide whether this will get eventually implemented or not.

My proposal for this would be something like:

  spl_function_autoload_register( callback(function) )
and
  spl_constant_autoload_register( callback(constant) )
or
  spl_ns_autoload_register( callback(namespace, property ,type) )

But still - weird, mostly useless and overkill to implement just because someone does not like :: in his identifier.

I would also like to see this feature, especially in the context of function autoloading and procedural programming.

1) It would make PP in PHP way more pleasant & effective (no need to spam guards like require_once, no need for indirect dispatchers, obviously, not loading code you don't need for particular request).
For a language that grew on procedural programming paradigm it's a shame development in this area has been stalled for so many years (afair nothing have changed since 4 in this regard).

2) There is a lot of code that could profit, e.g. Drupal.

3) Hacking with classes has its cons, eg. performance (what would be relative difference between direct function call vs static method call and indirect (callbacks)?).

4) How hard can it be? Checking for registered callback and running the procedure before firing error.

Proposed interface by shiranai7 at hotmail dot com looks ok.

> But still - weird, mostly useless and overkill to implement just because 
someone does not like :: in his identifier.

I disagree that this is mostly useless - far from it. If we had autoloading based 
on namespace access then namespace-based package/bundle management becomes 
trivial.
Frameworks are having to implement this themselves at present, to take an example 
from Laravel we have to call:
Laravel\Bundle::start($bundle_name);
before we can access code in that bundle. Would be great if instead we could use 
the existing language features and just use a namespace to automatically load 
that bundles code.

Agreed with lcfsoft.

What's the point of namespacing if we are told to use static class methods 
instead?  To 
change underscores to backslashes because backslashes are "prettier" 
than underscores? That's called class encapsulation. We already had that 
feature.

Namespacing as a concept has been around for decades. For example, they were 
available in 
Perl in 1998. Namespaces as a concept is not inherently an OO feature. They are 
simply a 
container for a set of identifiers. Functions being valid identifiers in PHP.

Please reconsider.

Regards,

Hi. I am in no position to actually decide anything.

Using abstract classes was suggested by me as an alternative since abstract classes can contain both functions and constants and can be autoloaded in current version of PHP without any changes. Also there is virtually no performance penalty when calling a static method instead of plain function.

Nevertheless, I agree with your point - there is currently no native way to autoload namespaced functions and constants without use of a class wrapper or the require_once() statement. While the "all class way" is popular way to organise applications right now, this would be a nice thing to have in PHP.

In earlier comment I mentioned possible solution involving one or more spl_*_register() functions. While the first two (autoloading based on single function or constant) are not very pretty, the last one could be the solution we are looking for.

I have thought this through and I might create a RFC page with detailed description of how it would actually operate.

For now, consider this:

void spl_package_autoload_register (
  callable $autoload_function(namespace, type, name),
  [$throw = true],
  [$prepend = false]
)

bool spl_package_autoload_unregister (
  mixed $autoload_function
)

void spl_package_autoload_call(
  string $namespace,
  int $type, // SPL_PACKAGE_FUNCTION, SPL_PACKAGE_CONSTANT
  string $name
)

Note that the "package" prefix is used just for demonstration. It could be "namespace" or something else, but I think that "package" is better name for group of namespaced functions and constants.

Autoloading namespaces would be a useful feature.

This discussion actually demonstrates that (a) this bug tracker is
not suitable for that, and (b) discussion about this feature is
necessary.  So if you, or anybody else, is still interested in
this feature, please forward the request to the internals mailing
list.  For the time being, I'm suspending this ticket.