Nicolas,
namespace foo {
>> something(); // autoloaded as "something"
>> }
>>
>
> That makes sense *for me* for many reasons, but IMHO that's too confusing
> for a wider adoption.
> Because this doesn't work for function foo\strlen, the only reasonable way
> to work with such an autoloader would be to avoid using dynamic namespace
> resolution by always using some "use function" or "use namespace".
> That's very fragile...
>
How is it fragile? In fact, I would argue that relying on dynamic namespace
resolution (as happens today) is fragile. Because you can't know at compile
time (or before hand) what a function will resolve to. That's fine when you
want polymorphism, but when you don't (which is most of the time that
you're calling a named function) it's not much short of fragile.
This encourages explicit, one-execution-path code. I fail to see how that
makes things worse than today... In fact, I see it making this better...
> I order not to be the one who kills a proposal and be constructive:
>
> Would some kind of namespace initializers be a good idea?
>
> That could work this way:
>
> Any time a non existing function or constant is required, a registered
> namespace initializer would be loaded. The big difference being that it
> would happen *BEFORE* fallback namespace resolution. The registered
> namespace loader would be given only the namespace part of the required
> symbol, and that would happen only once per namespace.
>
> That would have a performance impact, but I would be interested in seeing
> real benchmarks. May be we can find a way to make the mechanism light
> enough.
>
> For this performance reason, I would suggest having a registering function
> that take the exact namespace for which the loader matches as first
> argument:
> spl_namespace_register($namespace[, callable $autoload_function)
>
> $autoload_function would be called only for symbols in $namespace.
>
> What do you think ?
> Is it worth discussing that further?
>
It's an interesting thought. I think I'd rather see first-class support for
modules, but not quite sure there.
Actually, thinking about it slightly more, this appears to be trying to
hack namespaces into first-class modules.
Right now, a namespace is nothing more than compiler aided copy/paste (with
the exception of global fallback for functions and constants). It's just a
prefix added on to the construct's name.
To do this right, you could do it by parsing the name at each dispatch, and
then doing a hash table lookup to see if it's been loaded or not yet.
But if we're going down that route, why not take the next logical step and
make modules first class citizens (with a symbol table, where classes,
functions and constants are members of said module, rather than just
floating with prefixed names. That way we can attach metadata, access
permissions, events, etc around the module, and not just hack in one
additional thing.
Obviously this is a massive undertaking and quite off topic from here. But
if it's worth discussing further, let's open another thread.
Anthony
