Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68819
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <c41a7c04f69d2499a17a94e24b735bd8@mail.gmail.com>
References: <CAAyV7nFRfuu0dGnu0FV1ehkqwQR6=dUFSHMP=6CJsAVWghCADg@mail.gmail.com>
	<5220262A.6040702@sugarcrm.com>
	<CAESVnVr18CAAqr4oZHB9KKnAs9Ry-gQFsR2icE8XxLr8w+knNQ@mail.gmail.com>
	<5220437A.7050008@sugarcrm.com>
	<CALtuQzAjChxqOWNzkcd09c_UsoNe6XtCfTM6ADDoQMgZt-A_UA@mail.gmail.com>
	<5220D212.3010101@sugarcrm.com>
	<CALtuQzBhDTKqKRfg062TMhNfYFrkdDsMv5ZK2NrWS6m=C4JuZQ@mail.gmail.com>
	<c41a7c04f69d2499a17a94e24b735bd8@mail.gmail.com>
Date: Sun, 1 Sep 2013 17:23:10 +0100
Message-ID: <CA+yzxZh+pOJqYfrnZBDA33j+praP_PUP3D==Y_aYe0+HHx2vrQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals <internals@lists.php.net>, 
	Sebastian Krebs <krebs.seb@gmail.com>, Anthony Ferrara <ircmaxell@gmail.com>, 
	Sara Golemon <pollita@php.net>
Content-Type: multipart/alternative; boundary=001a11c25bda2768fe04e554dfc8
Subject: RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading
From: admacedo@gmail.com (Daniel Macedo)

--001a11c25bda2768fe04e554dfc8
Content-Type: text/plain; charset=ISO-8859-1

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!

--001a11c25bda2768fe04e554dfc8--