RFC __autodefine / spl_autodefine

Hi Sebastien,

__autoload() should die (as in get deprecated ASAP and later removed)

I couldn't find anything about your opinions on this so I was wondering if
you could elaborate. Do you consider autoloading as a bad practice or just
that spl_autoload_register should be used to add relevant
functions/closures?

__autoload() works fine if you have exactly one implementation for your entire
system with exactly one set of logic for how to map a class name to a file
name. As soon as you try to mix two different libraries together, fatal
error.

spl_autoload() does not suffer from this short-sighted problem but
accomplishes the same goal in a much more robust fashion.

Any new meta-auto-load mechanism should forego the dead-end that is a single
unique __auto*() function and just use a design that actually works, aka
spl_autoload() or similar.

With that said, I like the idea of generalizing autoload to include functions
et al. Autoloading functions would make my life a lot easier. :-) To be
fair, though, half of the potential benefits the OP listed are already solved
by using a version control system. Any version control system. If you're
still having collisions at the file level when two people work on the same
file it's because you're an idiot and are not using version control (or the
changes touch each other, in which case this proposal wouldn't help you
anyway).

The main advantage of this proposal would be lazy-loading of functions. I
don't think autoloading methods makes any sense since classes cannot be split
between files anyway.

I'm not entirely sure what else is actually reasonable to autoload. Classes,
Interfaces, Functions, and Traits make up the scope of first-class code
structures, don't they? Autoloading a variable doesn't even make sense to me,
and include files are already handled by include[_once].

--Larry Garfield

With that said, I like the idea of generalizing autoload to include
functions et al. Autoloading functions would make my life a lot easier.
:-)

Yes, the alternative solution is to write a wrapper function:
somefunc($a, $b) becomes ppcall("somefunc", $a, $b)
Works but if we can get this in PHP itself it will be much better.

Background: I am a Drupal developer. We already call most of our functions
indirectly via call_user_func_array(). Please for the love of god don't add
another slow function call on top of that which we'd need to use for lazy-
loading functions. :-)

To be fair, though, half of the potential benefits the OP listed are
already solved
by using a version control system. Any version control system. If
you're still having collisions at the file level when two people work on
the same file it's because you're an idiot and are not using version
control (or the changes touch each other, in which case this proposal
wouldn't help you anyway).

I disagree (but otoh, I am an idiot :-)). I just think there is no
conceptual need to group functions into a file.
I also don't believe in distributed vcs (probably idiotic again :-)).
The problem of integrating code is simply postponed with a dvcs.
At work we have good experiences with a centralized code repository
where people can work together, where backups are taken care of and
were revision history is built in. Integration issue are solved before
the code is touched.

I said nothing about a DVCS (although having worked with Git for the past year
I have grown quite fond of it). That is, however, irrelevant to the issue at
hand. You could use CVS and avoid the file-collision problem you describe.
Hell, you could probably even use RCS if you wanted to be really retro/stupid.
Any VCS that doesn't resolve the issue you describe (two people edit different
parts of the same file and the changes need to be integrated) should be
deleted outright for the good of mankind, and any project that is developed
without the use of a VCS capable of doing so should be abandoned on the
grounds that the team working on it doesn't know what they're doing. Just
sayin'. :-)

Also, I think it is crazy I have to do a grep on a filesystem to find
out in which file a function is defined (e.g. grep -i -l "ion
pick_date_widget"). I know, documentation etc. But that argument only
works when a system is in good shape when you take over. Why can't I
just see by the file name what definition hides inside?

I am on the record stating that the Java-style class-per-file organization
strategy is quite dumb in PHP. To do one-function-per-file as well strikes me
as ludicrous and is not at all a pattern we should be supporting. I recall a
colleague of mine once benchmarking a user-space implementation of such a
strategy and the performance implications being horrific.

As for knowing what functions are in a file, that's what a proper file name is
for: foo.inc contains functions relating to the "foo" system. If grep isn't
your cup of tea, there's a half-dozen IDEs that are quite capable of "click to
go to definition" functionality of some form.

Really, I'm in favor of function-level autoloading but you're making all of
the wrong arguments to support it. :-)

The main advantage of this proposal would be lazy-loading of functions.
I don't think autoloading methods makes any sense since classes cannot be
split between files anyway.

I think I was not clear with my remark on __call and __callStatic. I
think autodefining of methods is already possible by using __call and
__callStatic for that. The __call is used in this example for
dynamically adding methods to a class:
http://www.php.net/manual/en/function.call-user-func.php#89636. The
same __call function can be used to dynamically add code to the class.
But I think it would be better if the run time would do this in a
uniform way via autodefine.
The minimal definition in my view for a class would be "class
SomeClass {}" or "class SomeClass;" . But then classes resemble
namespaces to much (but in my view a class can also be viewed as a
namespace for a set of variables and functions). This is however
getting to theoretical, so lets keep it simple and let's assume that
the minimal definition of a class should have its variables, like this
"class SomeClass { var a; var b; }" and that methods can be added
dynamically.

A class is not even remotely the same as a namespace. A class is a data type.
You can use a class as if it were a poor-man's namespace but that's just as
much a hack as having parallel named functions that really ought to be methods
and passing a by-convention-opaque data structure to them. No, actually it's
even more of a hack. (Note: Sadly Drupal does the former far too often. I'm
working on ripping those out. <g>)

Also, __call() does not add a method to a class. You cannot add a method to a
class at runtime. In PHP 5.4 you can (assuming this went in; I think it did)
bind a closure to an object in a way that gets called like a method, but
that's an entirely different animal. Believe me, I've done some unholy things
with __call() trying to emulate what you describe, and lazy-loading of methods
is entirely irrelevant.

I'm not entirely sure what else is actually reasonable to autoload.
Classes, Interfaces, Functions, and Traits make up the scope of
first-class code structures, don't they? Autoloading a variable doesn't
even make sense to me, and include files are already handled by
include[_once].

Autodefining variables does make sense. Suppose you have a variable
called "$language" which is an array with a lot of language items and
that you have put this array somewhere. Current practices forces you
think what the possible paths are how the variable is accessed and
then include this array at the proper places. So far so good. But
things change in time and code is added to the system and suddenly the
variable is referenced via a path which was not foreseen. Current
practice forces you to rethink the include locations. But what happens
in reality? Most people simply include all the files somewhere
upfront, just to be sure. Again a lot of code parsed and processed
which may not be executed. Wouldn't it be much more elegant to define
the variable when it is first referenced?
Of course, this could be emulated with a function that would be
autodefined, so that is why I chose the minimal solution to not have
variables autodefined.

An application doesn't have variables. A scope has variables. A function or
method has variables. The closest you get to "an application having
variables" is globals, and if you're relying on that then you've already
screwed up your architecture royally. (Yep, I've worked on a system that used
globals as its main form of inter-system communication. Especially for the
template layer. I wish I was joking.)

If such logic is properly placed in a function or class, as you should be
doing, then current autoload or a function-level autoload would handle it and
you're done.

But another interesting option for autodefining variables is that you
are able to track which variables are used in your application. The
fun thing is that you can do this in every environment. For
development it is interesting to see if you are using variables which
you don't recognize (typo's) or don't want to use (e.g.
$HTTP_POST_VARS), for testing it is interesting to see if your test
cases are using the most important variables and for production it is
interesting to see which variables are used at all and which never.
The paragraph above applies of course to all objects that can be
autodefined. As pointed out in the RFC, autodefine enables you to get
more insight and thus more control over your codebase.

That's what a taint mode, E_ALL / E_STRICT, or runtime analysis tool is for.
It's not something that belongs in a runtime part of the language. If
anything, autoloading variables would make typos and such harder to track
down, harder to debug, and harder to comprehend.

Really, I want to like your RFC because I've wanted function-level autoloading
for a long time. It would make my life a ton easier. Please, please, please
make good arguments for it instead of coming up with use cases that would make
any responsible developer start with rm -rf as a way to debug a system. :-)
You'll never convince TPTB around here to accept it otherwise.

--Larry Garfield