Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50884
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.80 cause and error)
To: internals@lists.php.net
Date: Mon, 6 Dec 2010 22:44:16 -0600
User-Agent: KMail/1.13.5 (Linux/2.6.34.7-0.5-desktop; KDE/4.4.4; x86_64; ; )
References: <AANLkTin2X62fd=-5Wksww_qy8y+beXTxJTkrDvWzqXoq@mail.gmail.com> <4CFD4131.8070300@php.net> <AANLkTikOKLx+0DgErKdQ2ZDAfLWhGQNW_J2v7pCPVzc2@mail.gmail.com>
In-Reply-To: <AANLkTikOKLx+0DgErKdQ2ZDAfLWhGQNW_J2v7pCPVzc2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-ID: <201012062244.16530.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] RFC __autodefine / spl_autodefine
From: larry@garfieldtech.com (Larry Garfield)

On Monday, December 06, 2010 6:59:08 pm Ross Masters wrote:
> 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