On Wednesday, December 08, 2010 6:05:05 am Loon, Reinier van wrote:
> > 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
