[RFC] Function autoloading through spl_autoload* View as Markdown

Ferenc Kovacs wrote:

I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.

Shouldn't the default type be T_CLASS|T_INTERFACE?

sorry for the late reply.
judging from your reply and the conversion on irc with Etienne, I
think that the usage of the token constants are ambiguous(we have
different token constants for classes and interfaces as you mentioned
for example).
originally I chose this because this would be fully backward
compatible, but now I think that we should add new constants.
what do you think?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

I understand the proposal, but I don't see any compelling reasons in the
RFC of why we actually need autoloading for functions? For classes it
makes sense because there is almost always a class to file mapping. For
functions (and constants) that is not the case, so I am wondering how
useful this function autoloading actually is.

As Sebastian already mentioned, if all functions in a namespace are
grouped into one file, it would be simple to load that file using such
a concept.

Hi,

Am 14.08.2011 15:55, schrieb Derick Rethans:

I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.

https://wiki.php.net/rfc/autofunc

I understand the proposal, but I don't see any compelling reasons in the
RFC of why we actually need autoloading for functions?

For the same reasons, why class-autoloading is useful: Loading when
needed and avoiding unnecessary repetitive include-statements.

For classes it
makes sense because there is almost always a class to file mapping. For
functions (and constants) that is not the case, so I am wondering how
useful this function autoloading actually is.

Like classes there may be also a function-to-filename-mapping,
especially now, since namespaces exists. It is very easy to extend the
PSR-0 standard (lets say: PSR-0.1 ;)) so functions and constants are
covered by it too:

• Constants and functions are in a file named after the namespace
  myNamespace\foo\bar => MyNamespace/foo/bar.php

When class-autoloading were introduced there were no ^real^
class-to-file-mapping too. You had to define it yourself the time, when
you wrote your __autoload()-function. It's nearly the same with
functions/constants now, except that we are away from a single function
and that there are already ideas, that may cover such mappings already.

Or in my words: I don't see any reason, why
function-/constant-autoloading does not exists ;)

cheers,
Derick

Regards,
Sebastian

I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.

https://wiki.php.net/rfc/autofunc

I understand the proposal, but I don't see any compelling reasons in the
RFC of why we actually need autoloading for functions? For classes it
makes sense because there is almost always a class to file mapping. For
functions (and constants) that is not the case, so I am wondering how
useful this function autoloading actually is.

Namespaces support the following code types:

• Constants
• Functions
• Classes and Interfaces

Currently, autoloading in PHP allows us to dynamically identify and load
only classes and interfaces. However, not all code is written using OOP.
If a developer doesn't want to dive into include/require(_once) hell in
order to use their namespaced functions and/or constants, they have no
real options.

As an example, let's say I've created a procedural CMS or blog of some
sort. In there, I have a file like this:

<?php

namespace MyProjectName\Posts;

$entries = getEntries(date('Y'));
foreach ($entries as $entry) {
    displayEntrySummary($entry);
}

Next, assume the "getEntries" and "displayEntriesSummary" functions are
also in the namespace "MyProjectName\Posts". How does my code load those
functions?

Traditionally, we've used:

include_once 'MyProjectName/Posts/functions.php';

or

include_once __DIR__ . '/functions.php';

in our files. But why should we have to do that? Why are functions --
which make up the bulk of PHP's functionality, and which are the
bread-and-butter of many PHP projects -- get second-class status when it
comes to autoloading?

I can see an autoloader like this:

function autoloadFunctions($funcname, $type = SPL_AUTOLOAD_FUNCTION)
{
    if (!strstr($funcname, '\\')) {
        // we won't deal with un-namespaced functions
        return false;
    }
    $namespace = substr($funcname, 0, strrpos($funcname, '\\'));
    $funcfile  = str_replace('\\', DIRECTORY_SEPARATOR, $namespace)
               . `DIRECTORY_SEPARATOR` . 'Functions.php';
    return include_once($funcfile);
}

and that might autoload all functions in a given namespace. I've seen
other projects that put a function per-file -- so those might become
even more granular.

Basically, I don't see why we wouldn't want this functionality in PHP.
It makes namespaces practical and useful for procedural applications.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Hi,

Hi,

With this mail I don't want to talk to anyone directly, but I just want to
summarize the situation as far as I understand.

---

• Autoloading constants

---

No problem here: When the loading procedure fails, it gets converted to a
string like before. It may be a performance impact, but the code, that
relies on this "feature" gets flooded with warnings anyway.

---

• Autoloading functions

---

If I understood it right the only problem is, that someFunction() may be
in the global, as well as in the current namespace. This means, the
developer write a function in a namespace, that already exists in the global
scope, which remains to feel quite scary to me. Its way more confusing, that
(e.g.) strpos() don't behave, like expected and learned for years now.

It will affect only single namespaces, because if you want to call a
function from another namespace you must prefix it with a qualified or
full-qualified namespace anyway.
And last but not least: Currently you must include the files containing the
functions yourself. This means, that existing code is not affected,
because as long as no one removes the include-statements, it even not call
any autoloading. But when the developers decides to remove them, they
probably wants to use the autoloading, what means, that they (hopefully)
understand, how it works.

However, in my opinion the important part is to just make a decision the
sooner, the better, as long as there are not too much creepy code out there
(I don't know any and I can't imagine, that there is). Because functions
with namespace are quite unhandy without autoloading and I don't think, that
there is much use of it.

So the 2 possible solutions:

1:

• test namespace
• test global
• load namespace
• load global

2:

• test namespace
• load namespace
• test global
• load global

Also:

4:

• test namespace
• test global
• load namespace

Maybe
3:

• test namespace
• test global
• load global
• load namespace
  would be a solution too, but it seems a little bit curious, when I use
  namespaces, but it looks into the global scope first.

Regards,
Sebastian

Am 06.08.2011 13:15, schrieb Ferenc Kovacs:

Hi.

I would like to introduce this RFC which would provide function
autoloading through the spl_autoload facility without userland BC
breakage.

https://wiki.php.net/rfc/autofunc

--

--
Etienne Kneuss
http://www.colder.ch

Hi!

However, in my opinion the important part is to just make a decision the
sooner, the better, as long as there are not too much creepy code out
there (I don't know any and I can't imagine, that there is). Because
functions with namespace are quite unhandy without autoloading and I
don't think, that there is much use of it.

We already made the decision, when we introduced the namespaces and made
the resolution order what it is now. And we considered all the variants
and discussed all the arguments brought here back then.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227