Re: [DRAFT] [RFC] Function autoloading

From: Date: Thu, 01 Jan 1970 00:00:00 +0000
Subject: Re: [DRAFT] [RFC] Function autoloading
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Daniel Macedo <[email protected]> wrote:
> I can accept not supporting PSR directly but implementing the class
> autoloader and stating "internals believes autoload in should exist, just
> doesn't specify/support any particular implementation", this makes sense,
> although I like PSR and don't really see others that make (as much) sense.
> 
> This means internally we recognise an issue, resolve it in a general
> manner and allow some decisions up to the developer.
> 
> Most of us developing now have the dreaded Utils class, it's an ugly hack
> filled with static methods... Yes, it might be almost the same as a
> namespaced bunch of classes, if you don't share states between those methods.
> 
> Now consider this: PSR or any autoloader implementation allows for better
> sharing and code reuse; AND it makes sense to allow this for OOP as well
> as procedural code!
> 
> I think Anthony and Nikki can see the forest from the trees, and that the
> core should support a number of use cases, not just what you currently
> use (and developers miss this functionality Anthony proposes)
> 
> Having namespaced functions now allows for a function autoloader that
> uses the namespace as the file: awesome, great, let's do this!
> 
> If not by looking at others code, or at Python, or at the
> Class/Constants/Namespaced-Functions all needing to have and being
> positively impacted by an autoloader... at least try and foresee the
> sense it makes for non-oop-but-maintained-by-smart-people to have an autoloader!
> 
> Try to understand that this need exists and, it makes sense as a step
> into organising and refactoring legacy applications and for
> structure/grouping of classes, functions and constants, if only for the
> sake of organisation, but also for code-sharing, code reuse AND less
> managing of 20 *_once calls on top of every file in legacy applications! ;)
> 
> Also as a bonus, a bunch of functions/constants filled files could got
> through a request never being read/included if never used, this alone should warrant pause!

From a user land developer, having the option of doing something is always
better then not. You guys are doing a lot of great work for us mere
mortals, why not also give us this option? It's been stated that thanks to
a function short circuit that it would not cost performance and would add
functionally. To me that seems like a win, win.

-- 
Thank You For Your Time.


Thread (72 messages)

« previous php.internals (#70921) next »