Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94895
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.49 cause and error)
MIME-Version: 1.0
Date: Sun, 7 Aug 2016 13:19:35 +0200
Message-ID: <CADqTB_gBFM_2yNDQemPs68Fab4Hbd8pGj38a3-HSQ+CRcnDyvA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114e3cae854ceb053979797a
Subject: Function auto-loading
From: rasmus@mindplay.dk (Rasmus Schultz)

--001a114e3cae854ceb053979797a
Content-Type: text/plain; charset=UTF-8

I'd really like to see the function auto-loading proposal revived and/or
possibly simplified.

The fact that functions are hard (in some cases impossible) to reach by
manually issuing require/include statements is, in my opinion, half the
difficulty, and a much more deeply rooted language problem exacerbating
what should be trivial problems - e.g. install a Composer package, import
(use) and call the functions.

Looks like a fair amount of work and discussion was done in 2013 on this
RFC:

https://wiki.php.net/rfc/function_autoloading

There was a (now stale) proof of concept implementation for the parent RFC
as well:

https://wiki.php.net/rfc/function_autoloading2

What happened?

It looks like the discussion stalled mostly over some concerns, including
reservations about performance, which were already disproved?

One issue apparently was left unaddressed, that of whether a call to an
undefined function should generate an auto-load call to a namespaced or
global function - I think this would not be difficult to address: trigger
auto-loading of the namespaced function first, check if it was loaded, and
if not, trigger auto-loading of the global function. Most likely a PSR
along with Composer auto-loading features will favor a best practice of
shipping packages with namespaced functions only, so the performance
implications of checking twice would be negligible in practice.

Being basically unable to ship or consume purely functional packages leaves
the functional side of the language largely an unused historical artifact,
which is sad. Keeping things functional and stateless often lead to more
predictable and obvious code - I think the absence of good support for
functions encourages a lot of over-engineering, e.g. developers
automatically making everything a class, not as a design choice, for the
sole reason of being able to ship and reuse what should be simple functions.

This RFC looks pretty solid to me.

What will it take to get this rolling again?

--001a114e3cae854ceb053979797a--