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?
I'd really like to see the function auto-loading proposal revived and/or
possibly simplified.
+1 from my side for the revival. I would also love to see auto-loading
of namespaced constants like we have it for class constants.
--
Richard "Fleshgrinder" Fussenegger
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.
I feel like the problem here did not get across properly. Calling the
autoloader if a global function with the name exists will totally kill
performance. This means that every call to strpos() or any of the other
functions in the PHP standard library will have to go through the
autoloader first, unless people use fully qualified names (which,
currently, they don't). This is completely out of the question.
(The case where neither the namespaced nor the global function exists is
not the problem. In that case calling the autoloader for the namespaced and
non-namespaced names in sequence is of course unproblematic.)
Nikita
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?
Of course calling e.g. strpos() should not trigger the auto-loader
repeatedly - can we cache the information that the auto-loader was
attempted once during the current script execution? so that e.g. only the
first call to strpos() triggers the auto-loader?
I suppose it would still happen once for every namespace from which
strpos() gets called, so maybe this optimization doesn't help much.
I guess I'd say, benchmark it before making assumptions? Maybe the
performance hit turns out to be negligible in practice. Hard to say.
If a performance hit is inevitable, but marginal, I hope that we do not let
micro-benchmarks stand in the way of improving the language?
With PHP 7, the language is in many ways almost twice as fast as it was
before. I think it's fair to say, PHP has problems that are much bigger
than performance - to most developers, performance is not a pain point
anymore, if it was before PHP 7.
I wish that I could change your focus from performance concerns to actually
focusing on the language itself.
It seems that me that recent performance improvements have become somewhat
of a bottleneck that prevents new features and (worse) missing features
from completing and improving the language?
The performance improvements could just as well be viewed as a factor that
creates new elbow room for new features and language improvements, which,
long term, likely have much more value to more developers than the
performance of micro-benchmarks.
At the end of the day, for like 9 our of 10 projects, PHP's core
performance is not the bottleneck - things like database queries are. The
cost of developing a project is also generally unrelated to core
performance of the language. Hardware gets cheaper and faster every day. So
who or what are we optimizing for?
I don't mean to get too side-tracked from the original conversation here,
but we should be designing for developers - not for machines. The language
is more than fast enough for what most developers need it for - and still
nowhere near fast enough for, say, a JSON or XML parser, the kind of things
that require C or assembly level performance, and I really don't believe
there's a substantial segment of use-cases that fall in between - for most
things, either you need performance that PHP can't get near, or you need
language features and convenience that low-level languages can't deliver.
We're not competing with C - and if we're competing with other scripting
languages on performance, we're already in a pretty good position, and
people who select a scripting language aren't basing their choice on raw
performance in the first place; if that was their concern, they'd pick C.
We should focus on competing with other scripting languages on features,
convenience, productivity, etc. - if our main concern is competing on
low-level concerns like performance, those concerns will override the
points that really matter to developers who choose a high-level scripting
language, and we will lose.
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.I feel like the problem here did not get across properly. Calling the
autoloader if a global function with the name exists will totally kill
performance. This means that every call tostrpos()or any of the other
functions in the PHP standard library will have to go through the
autoloader first, unless people use fully qualified names (which,
currently, they don't). This is completely out of the question.(The case where neither the namespaced nor the global function exists is
not the problem. In that case calling the autoloader for the namespaced and
non-namespaced names in sequence is of course unproblematic.)Nikita
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?
What should be the difference between a static method on a autoloaded class?
I guess that it could be done currently by use a static method.
In this case, I know exactly what method should be called, without
depends of an autoloader response.
class String {
public static function strpos(...) { ... }
}
In this case, I just need to call String::strpos(...) and done.
I don't know if I'm missing something.
2016-08-07 9:07 GMT-03:00 Rasmus Schultz rasmus@mindplay.dk:
Of course calling e.g.
strpos()should not trigger the auto-loader
repeatedly - can we cache the information that the auto-loader was
attempted once during the current script execution? so that e.g. only the
first call tostrpos()triggers the auto-loader?I suppose it would still happen once for every namespace from which
strpos()gets called, so maybe this optimization doesn't help much.I guess I'd say, benchmark it before making assumptions? Maybe the
performance hit turns out to be negligible in practice. Hard to say.If a performance hit is inevitable, but marginal, I hope that we do not let
micro-benchmarks stand in the way of improving the language?With PHP 7, the language is in many ways almost twice as fast as it was
before. I think it's fair to say, PHP has problems that are much bigger
than performance - to most developers, performance is not a pain point
anymore, if it was before PHP 7.I wish that I could change your focus from performance concerns to actually
focusing on the language itself.It seems that me that recent performance improvements have become somewhat
of a bottleneck that prevents new features and (worse) missing features
from completing and improving the language?The performance improvements could just as well be viewed as a factor that
creates new elbow room for new features and language improvements, which,
long term, likely have much more value to more developers than the
performance of micro-benchmarks.At the end of the day, for like 9 our of 10 projects, PHP's core
performance is not the bottleneck - things like database queries are. The
cost of developing a project is also generally unrelated to core
performance of the language. Hardware gets cheaper and faster every day. So
who or what are we optimizing for?I don't mean to get too side-tracked from the original conversation here,
but we should be designing for developers - not for machines. The language
is more than fast enough for what most developers need it for - and still
nowhere near fast enough for, say, a JSON or XML parser, the kind of things
that require C or assembly level performance, and I really don't believe
there's a substantial segment of use-cases that fall in between - for most
things, either you need performance that PHP can't get near, or you need
language features and convenience that low-level languages can't deliver.We're not competing with C - and if we're competing with other scripting
languages on performance, we're already in a pretty good position, and
people who select a scripting language aren't basing their choice on raw
performance in the first place; if that was their concern, they'd pick C.We should focus on competing with other scripting languages on features,
convenience, productivity, etc. - if our main concern is competing on
low-level concerns like performance, those concerns will override the
points that really matter to developers who choose a high-level scripting
language, and we will lose.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.I feel like the problem here did not get across properly. Calling the
autoloader if a global function with the name exists will totally kill
performance. This means that every call tostrpos()or any of the other
functions in the PHP standard library will have to go through the
autoloader first, unless people use fully qualified names (which,
currently, they don't). This is completely out of the question.(The case where neither the namespaced nor the global function exists is
not the problem. In that case calling the autoloader for the namespaced and
non-namespaced names in sequence is of course unproblematic.)Nikita
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?
--
David Rodrigues
On Sun, Aug 7, 2016 at 12:32 PM, David Rodrigues david.proweb@gmail.com
wrote:
What should be the difference between a static method on a autoloaded
class?I guess that it could be done currently by use a static method.
In this case, I know exactly what method should be called, without
depends of an autoloader response.class String {
public static function strpos(...) { ... }
}In this case, I just need to call String::strpos(...) and done.
I don't know if I'm missing something.
2016-08-07 9:07 GMT-03:00 Rasmus Schultz rasmus@mindplay.dk:
Of course calling e.g.
strpos()should not trigger the auto-loader
repeatedly - can we cache the information that the auto-loader was
attempted once during the current script execution? so that e.g. only the
first call tostrpos()triggers the auto-loader?I suppose it would still happen once for every namespace from which
strpos()gets called, so maybe this optimization doesn't help much.I guess I'd say, benchmark it before making assumptions? Maybe the
performance hit turns out to be negligible in practice. Hard to say.If a performance hit is inevitable, but marginal, I hope that we do not
let
micro-benchmarks stand in the way of improving the language?With PHP 7, the language is in many ways almost twice as fast as it was
before. I think it's fair to say, PHP has problems that are much bigger
than performance - to most developers, performance is not a pain point
anymore, if it was before PHP 7.I wish that I could change your focus from performance concerns to
actually
focusing on the language itself.It seems that me that recent performance improvements have become
somewhat
of a bottleneck that prevents new features and (worse) missing features
from completing and improving the language?The performance improvements could just as well be viewed as a factor
that
creates new elbow room for new features and language improvements, which,
long term, likely have much more value to more developers than the
performance of micro-benchmarks.At the end of the day, for like 9 our of 10 projects, PHP's core
performance is not the bottleneck - things like database queries are. The
cost of developing a project is also generally unrelated to core
performance of the language. Hardware gets cheaper and faster every day.
So
who or what are we optimizing for?I don't mean to get too side-tracked from the original conversation here,
but we should be designing for developers - not for machines. The
language
is more than fast enough for what most developers need it for - and still
nowhere near fast enough for, say, a JSON or XML parser, the kind of
things
that require C or assembly level performance, and I really don't believe
there's a substantial segment of use-cases that fall in between - for
most
things, either you need performance that PHP can't get near, or you need
language features and convenience that low-level languages can't deliver.We're not competing with C - and if we're competing with other scripting
languages on performance, we're already in a pretty good position, and
people who select a scripting language aren't basing their choice on raw
performance in the first place; if that was their concern, they'd pick C.We should focus on competing with other scripting languages on features,
convenience, productivity, etc. - if our main concern is competing on
low-level concerns like performance, those concerns will override the
points that really matter to developers who choose a high-level scripting
language, and we will lose.On Sun, Aug 7, 2016 at 1:29 PM, Nikita Popov nikita.ppv@gmail.com
wrote:On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz rasmus@mindplay.dk
wrote: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.I feel like the problem here did not get across properly. Calling the
autoloader if a global function with the name exists will totally kill
performance. This means that every call tostrpos()or any of the other
functions in the PHP standard library will have to go through the
autoloader first, unless people use fully qualified names (which,
currently, they don't). This is completely out of the question.(The case where neither the namespaced nor the global function exists is
not the problem. In that case calling the autoloader for the namespaced
and
non-namespaced names in sequence is of course unproblematic.)Nikita
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?
Perhaps the solution is to look at this as a forward-only feature, rather
than a backfill.
We only support autoloading for unambiguous names — if you want the
autoloader to be called, either
import the function with use, or use a [fully] qualified name.
This should remove the ambiguities and performance concerns.
- Davey
Perhaps the solution is to look at this as a forward-only feature, rather
than a backfill.We only support autoloading for unambiguous names — if you want the
autoloader to be called, either
import the function with use, or use a [fully] qualified name.This should remove the ambiguities and performance concerns.
I actually quite like this suggestion, because it fits with the use case
I see as being most common: replacing static-only classes with a
namespace of related functions. (Remember that "static classes" were
rejected at RFC in favour of exactly this.)
To be clear, the case we'd be "refusing" to autoload (other than global
functions themselves) would be a function in the exact current namespace:
namespace Acme\Foo\Bar;
do_something(); // won't autoload
But that only matters if namespace "\Acme\Foo\Bar" is split over
multiple files. In this case, the declaration of
"Acme\Foo\Bar\do_something()" would probably be in the same file anyway,
so not need autoloading.
Given that we have hierarchical namespaces, this seems a more likely
scenario:
namespace Acme\Foo\Bar;
// function autoload for 'Acme\Foo\Bar\Utilities\do_something'
Utilities\do_something();
Or importing as an alias:
namespace Acme\Foo\Bar;
use Acme\Stuff\Utilities as Util;
// function autoload for 'Acme\Stuff\Utilities\do_something'
Util\do_something();
Note that an unqualified function call "do_something()" already doesn't
look in any imported namespaces, so "use Acme\Stuff\Utilities;" doesn't
do anything to function name resolution.
So we would be defining a simple rule: "the function autoloader will be
called at run time for any namespace-qualified function name which is
not already defined".
This feels like a better compromise than an autoload cache, because I
can see the invalidation rules getting messy, and heavily-used global
functions still firing the autoloader for many different possible prefixes.
Regards,
Rowan Collins
[IMSoP]
On Mon, Aug 8, 2016 at 12:51 PM, Rowan Collins rowan.collins@gmail.com
wrote:
Perhaps the solution is to look at this as a forward-only feature, rather
than a backfill.We only support autoloading for unambiguous names — if you want the
autoloader to be called, either
import the function with use, or use a [fully] qualified name.This should remove the ambiguities and performance concerns.
I actually quite like this suggestion, because it fits with the use case I
see as being most common: replacing static-only classes with a namespace of
related functions. (Remember that "static classes" were rejected at RFC in
favour of exactly this.)To be clear, the case we'd be "refusing" to autoload (other than global
functions themselves) would be a function in the exact current namespace:namespace Acme\Foo\Bar;
do_something(); // won't autoloadBut that only matters if namespace "\Acme\Foo\Bar" is split over multiple
files. In this case, the declaration of "Acme\Foo\Bar\do_something()" would
probably be in the same file anyway, so not need autoloading.Given that we have hierarchical namespaces, this seems a more likely
scenario:namespace Acme\Foo\Bar;
// function autoload for 'Acme\Foo\Bar\Utilities\do_something'
Utilities\do_something();Or importing as an alias:
namespace Acme\Foo\Bar;
use Acme\Stuff\Utilities as Util;
// function autoload for 'Acme\Stuff\Utilities\do_something'
Util\do_something();Note that an unqualified function call "do_something()" already doesn't
look in any imported namespaces, so "use Acme\Stuff\Utilities;" doesn't do
anything to function name resolution.So we would be defining a simple rule: "the function autoloader will be
called at run time for any namespace-qualified function name which is not
already defined".This feels like a better compromise than an autoload cache, because I can
see the invalidation rules getting messy, and heavily-used global functions
still firing the autoloader for many different possible prefixes.
I like this idea as well. In a previous thread I suggested to delay the
autoloader call for unqualified function calls until after the check for an
existing global function. But just not calling the autoloader at all for
unqualified calls is the better solution, as it removes one pretty
arbitrary factor (does this global function exist?) from the autoloader
behavior.
Nikita
Hi!
Of course calling e.g.
strpos()should not trigger the auto-loader
repeatedly - can we cache the information that the auto-loader was
attempted once during the current script execution? so that e.g. only the
first call tostrpos()triggers the auto-loader?
I think triggering it even once for every internal function in the
code may be too much.
I suppose it would still happen once for every namespace from which
strpos()gets called, so maybe this optimization doesn't help much.
Exactly. Also, caching stuff assumes static environment. What if it
changes, e.g. autoloader gets different configuration?
Stas Malyshev
smalyshev@gmail.com
I feel like the problem here did not get across properly. Calling the
autoloader if a global function with the name exists will totally kill
performance. This means that every call tostrpos()or any of the other
functions in the PHP standard library will have to go through the
autoloader first, unless people use fully qualified names (which,
currently, they don't). This is completely out of the question.
Interesting. I come to a different conclusion: this a great opportunity to
get developers to use the fully qualified names. Performance is an
incredibly motivating force even in many situations when it shouldn't be.
I feel like the problem here did not get across properly. Calling the
autoloader if a global function with the name exists will totally kill
performance. This means that every call tostrpos()or any of the other
functions in the PHP standard library will have to go through the
autoloader first, unless people use fully qualified names (which,
currently, they don't). This is completely out of the question.Interesting. I come to a different conclusion: this a great opportunity to
get developers to use the fully qualified names. Performance is an
incredibly motivating force even in many situations when it shouldn't be.
An example just to focus the mind:
namespace Lovely\New\Code;
class Blah {
function __construct(array $foo) {
foreach ( $foo as $item ) {
if ( strpos('blah', $item) !== 0 ) {
// ...
}
}
}
}
This will repeatedly call the function autoloader for
"Lovely\New\Code\strpos". The fully qualified name in this case is
"\strpos".
I think saying "add a backslash in front of your function names to avoid
them being slow" will just lead to lots of "lol wtf php sux".
If we wanted to make the \ mandatory, then the name resolution for
functions could have had no fallback, just like class names. The reasons
for having that fallback presumably still apply, so it doesn't make
sense to now declare it "broken by design, please avoid".
On the other hand, saying "you can autoload functions from another
namespace using qualified names or 'use function'" sidesteps the
fallback issue, and sounds like a reasonable, non-BC-breaking, feature.
Regards,
Rowan Collins
[IMSoP]
IMHO if there were possibility to provide scalar objects like in Nikic
extension
https://nikic.github.io/2014/03/14/Methods-on-primitive-types-in-PHP.html
most of str* and many other functions could be called wythout FQN simply
from variable. Most of global scope functions interacting with scalars
could be called throught object handlers. In many legacy applications there
still could be possibility to call global functions. Most of legacy
applications have no namespace (Wordpress) so there is even no need for FQN
for function calls.
2016-08-08 16:56 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
I feel like the problem here did not get across properly. Calling the
autoloader if a global function with the name exists will totally kill
performance. This means that every call tostrpos()or any of the other
functions in the PHP standard library will have to go through the
autoloader first, unless people use fully qualified names (which,
currently, they don't). This is completely out of the question.Interesting. I come to a different conclusion: this a great opportunity to
get developers to use the fully qualified names. Performance is an
incredibly motivating force even in many situations when it shouldn't be.An example just to focus the mind:
namespace Lovely\New\Code;
class Blah {
function __construct(array $foo) {
foreach ( $foo as $item ) {
if ( strpos('blah', $item) !== 0 ) {
// ...
}
}
}
}This will repeatedly call the function autoloader for
"Lovely\New\Code\strpos". The fully qualified name in this case is
"\strpos".I think saying "add a backslash in front of your function names to avoid
them being slow" will just lead to lots of "lol wtf php sux".If we wanted to make the \ mandatory, then the name resolution for
functions could have had no fallback, just like class names. The reasons
for having that fallback presumably still apply, so it doesn't make sense
to now declare it "broken by design, please avoid".On the other hand, saying "you can autoload functions from another
namespace using qualified names or 'use function'" sidesteps the fallback
issue, and sounds like a reasonable, non-BC-breaking, feature.Regards,
Rowan Collins
[IMSoP]--
--
pozdrawiam
Michał Brzuchalski
I think saying "add a backslash in front of your function names to avoid
them being slow" will just lead to lots of "lol wtf php sux".
They'll say the same when function and class autoloading don't work the
same way anyway. I think unifying their behavior over time is the best
solution forward. Yes, I'm talking about a BC break eventually, but the
suggestion to autoload only fully qualified function names could buy us the
time to make that BC break less severe.
2016-08-08 18:00 GMT+02:00 Levi Morrison levim@php.net:
I think saying "add a backslash in front of your function names to avoid
them being slow" will just lead to lots of "lol wtf php sux".They'll say the same when function and class autoloading don't work the
same way anyway. I think unifying their behavior over time is the best
solution forward. Yes, I'm talking about a BC break eventually, but the
suggestion to autoload only fully qualified function names could buy us the
time to make that BC break less severe.
Loading only full qualified names will lead to strange bugs.
Loading only full qualified names will lead to strange bugs.
The suggestion is to require qualified names (at least one \ in the
call), not to require fully qualified names (leading \ and full
namespace path). Function name resolution already requires that to
reference anything other than a global function, or the exact current
namespace.
The only scheme I can think of where it would matter is
one-function-per-file, like Smarty's plugin loader.
file foo.php
namespace Acme\Plugins;
function foo() { echo 'Hello world'; }
file bar.php
namespace Acme\Plugins;
function bar() { foo(); } # will not autoload
Compared to "hundreds of lines of existing code will go slowly unless
you liberally sprinkle with ", having to remind people not to do that
seems like a small price to pay.
Regards,
Rowan Collins
[IMSoP]
I think saying "add a backslash in front of your function names to avoid them being slow" will just lead to lots of "lol wtf php sux".They'll say the same when function and class autoloading don't work the
same way anyway. I think unifying their behavior over time is the best
solution forward. Yes, I'm talking about a BC break eventually, but the
suggestion to autoload only fully qualified function names could buy us
the time to make that BC break less severe.
Do you mean eventually changing the name resolution rules for functions
to match those for classes? I wasn't around at the time it was
discussed, and if we were adding them now would be tempted to say the
leading \ should always be mandatory, just like it is for classes. But
since we have what we have, I don't see that big an advantage to
changing it.
If not, I don't see why we ever need to be able to autoload global
functions. "You want autoloading? Put it in a namespace." Like I say,
that leaves the very small edge case of a single namespace spanning
multiple files, and an autoloader implementation able to include one of
them when a function is called from another.
Regards,
Rowan Collins
[IMSoP]
If not, I don't see why we ever need to be able to autoload global
functions. "You want autoloading? Put it in a namespace." Like I say, that
leaves the very small edge case of a single namespace spanning multiple
files, and an autoloader implementation able to include one of them when a
function is called from another.
I'm not sure why you would think a single namespace spanning multiple files
is a "very small edge case". I disagree. Here are some libraries I am aware
of off the top of my head that use functions the same namespace across
multiple files:
As well as several of my personal projects. I do not think this is a "very
small edge case."
If not, I don't see why we ever need to be able to autoload global functions. "You want autoloading? Put it in a namespace." Like I say, that leaves the very small edge case of a single namespace spanning multiple files, and an autoloader implementation able to include one of them when a function is called from another.I'm not sure why you would think a single namespace spanning multiple
files is a "very small edge case". I disagree. Here are some libraries I
am aware of off the top of my head that use functions the same
namespace across multiple files:As well as several of my personal projects. I do not think this is a
"very small edge case."
The "iter" example looks a long way from being autoloadable whatever we
supported, but the example of one-function-per-file is definitely
relevant, so I stand corrected.
After a bit of clicking, I even managed to find a line which would fail
to autoload under the proposed limitation:
https://github.com/lstrojny/functional-php/blob/master/src/Functional/CompareObjectHashOn.php
return compare_on($comparison, $keyFunction);
Although interestingly, at the top of the file there is a (technically
unnecessary) "use function Functional\compose;" If there was a "use
function Functional\compare_on;" as well, we'd be fine. (The function
name would then become qualified at compile time and trigger autoloading
at run time.)
Unless there's a demonstrated, critical performance issue with
auto-loading of global functions, please, let's not cripple this feature
with inconsistencies from the get-go!
Sure, we could try to measure it, but remember that it's not just the
engine code that has the extra cost, it will actually call a userland
function every time you use a global function from inside a namespace if
you don't add a leading "". That userland function will probably do a
bunch of string comparisons before deciding it's not interested, and may
even try to stat a file or two. Those are really expensive operations,
so I think it's a long way from "micro-optimisation".
Unfortunately, function name resolution has this quirk that class name
resolution doesn't, so something's got to give.
Regards,
Rowan Collins
[IMSoP]
Unfortunately, function name resolution has this quirk that class name
resolution doesn't, so something's got to give.
I suppose.
Well, then, how about making the feature work consistently for all
functions, by coupling it directly to the "use function" statement?
In other words, the feature changes from being strictly about auto-loading
functions, to instead resolving an imported function - so it would be
triggered by the "use function" statement only, rather than by the use of
the function, and the resolved function pertains only to the scope of the
file.
A function resolver would simply need to return a callable:
register_function_resolver(function ($name) {
if ($name === "html") {
return function ($str) {
return htmlspecialchars($str, ENT_HTML5);
};
}
if (substr($name, 0, 5) === "iter\\") {
require_once VENDOR_PATH."/nikic/iter/src/bootstrap.php";
return $name;
}
});
This mechanism is probably a lot easier to explain and understand - and
works equally for global or namespaced functions.
It also lets you potentially do other weird shit, like overriding
var_dump() or hooking into certain function calls - which could enable you
to do a bunch of evil, but I'm not really big on complicating features
solely to keep users from doing harm; simpler language features tend to
allow you to do more stuff - good or evil.
Likely the 99% use-case is simply for Composer to bootstrap your packages
for you, and this feature will permit you to do that.
Okay, so it doesn't deal with namespaced constants, and maybe this is me
being opinionated, but who's going to import constants one by one?
Constants are usually better off grouped together in a class. Although I
don't suppose there's any reason this concept couldn't be expanded to work
for constants as well, for completeness at least - though I have doubts
that very many people would care...
Anyways, just spitballing here :-)
On Mon, Aug 8, 2016 at 7:54 PM, Rowan Collins rowan.collins@gmail.com
wrote:
If not, I don't see why we ever need to be able to autoload global functions. "You want autoloading? Put it in a namespace." Like I say, that leaves the very small edge case of a single namespace spanning multiple files, and an autoloader implementation able to include one of them when a function is called from another.I'm not sure why you would think a single namespace spanning multiple
files is a "very small edge case". I disagree. Here are some libraries I
am aware of off the top of my head that use functions the same
namespace across multiple files:As well as several of my personal projects. I do not think this is a
"very small edge case."The "iter" example looks a long way from being autoloadable whatever we
supported, but the example of one-function-per-file is definitely relevant,
so I stand corrected.After a bit of clicking, I even managed to find a line which would fail to
autoload under the proposed limitation:https://github.com/lstrojny/functional-php/blob/master/src/
Functional/CompareObjectHashOn.phpreturn compare_on($comparison, $keyFunction);
Although interestingly, at the top of the file there is a (technically
unnecessary) "use function Functional\compose;" If there was a "use
function Functional\compare_on;" as well, we'd be fine. (The function name
would then become qualified at compile time and trigger autoloading at run
time.)Unless there's a demonstrated, critical performance issue with
auto-loading of global functions, please, let's not cripple this feature
with inconsistencies from the get-go!Sure, we could try to measure it, but remember that it's not just the
engine code that has the extra cost, it will actually call a userland
function every time you use a global function from inside a namespace if
you don't add a leading "". That userland function will probably do a
bunch of string comparisons before deciding it's not interested, and may
even try to stat a file or two. Those are really expensive operations, so I
think it's a long way from "micro-optimisation".Unfortunately, function name resolution has this quirk that class name
resolution doesn't, so something's got to give.Regards,
Rowan Collins
[IMSoP]
Unfortunately, function name resolution has this quirk that class name
resolution doesn't, so something's got to give.I suppose.
Well, then, how about making the feature work consistently for all
functions, by coupling it directly to the "use function" statement?In other words, the feature changes from being strictly about auto-loading
functions, to instead resolving an imported function - so it would be
triggered by the "use function" statement only, rather than by the use of
the function, and the resolved function pertains only to the scope of the
file.A function resolver would simply need to return a callable:
register_function_resolver(function ($name) { if ($name === "html") { return function ($str) { return htmlspecialchars($str, ENT_HTML5); }; } if (substr($name, 0, 5) === "iter\\") { require_once VENDOR_PATH."/nikic/iter/src/bootstrap.php"; return $name; } });This mechanism is probably a lot easier to explain and understand - and
works equally for global or namespaced functions.It also lets you potentially do other weird shit, like overriding
var_dump()or hooking into certain function calls - which could enable you
to do a bunch of evil, but I'm not really big on complicating features
solely to keep users from doing harm; simpler language features tend to
allow you to do more stuff - good or evil.Likely the 99% use-case is simply for Composer to bootstrap your packages
for you, and this feature will permit you to do that.Okay, so it doesn't deal with namespaced constants, and maybe this is me
being opinionated, but who's going to import constants one by one?
Constants are usually better off grouped together in a class. Although I
don't suppose there's any reason this concept couldn't be expanded to work
for constants as well, for completeness at least - though I have doubts
that very many people would care...Anyways, just spitballing here :-)
On Mon, Aug 8, 2016 at 7:54 PM, Rowan Collins rowan.collins@gmail.com
wrote:If not, I don't see why we ever need to be able to autoload global functions. "You want autoloading? Put it in a namespace." Like I say, that leaves the very small edge case of a single namespace spanning multiple files, and an autoloader implementation able to include one of them when a function is called from another.I'm not sure why you would think a single namespace spanning multiple
files is a "very small edge case". I disagree. Here are some libraries I
am aware of off the top of my head that use functions the same
namespace across multiple files:As well as several of my personal projects. I do not think this is a
"very small edge case."The "iter" example looks a long way from being autoloadable whatever we
supported, but the example of one-function-per-file is definitely
relevant,
so I stand corrected.After a bit of clicking, I even managed to find a line which would fail
to
autoload under the proposed limitation:https://github.com/lstrojny/functional-php/blob/master/src/
Functional/CompareObjectHashOn.phpreturn compare_on($comparison, $keyFunction);
Although interestingly, at the top of the file there is a (technically
unnecessary) "use function Functional\compose;" If there was a "use
function Functional\compare_on;" as well, we'd be fine. (The function
name
would then become qualified at compile time and trigger autoloading at
run
time.)Unless there's a demonstrated, critical performance issue with
auto-loading of global functions, please, let's not cripple this
feature
with inconsistencies from the get-go!Sure, we could try to measure it, but remember that it's not just the
engine code that has the extra cost, it will actually call a userland
function every time you use a global function from inside a namespace if
you don't add a leading "". That userland function will probably do a
bunch of string comparisons before deciding it's not interested, and may
even try to stat a file or two. Those are really expensive operations,
so I
think it's a long way from "micro-optimisation".Unfortunately, function name resolution has this quirk that class name
resolution doesn't, so something's got to give.Regards,
Related to this, I'd like to see stream (and stream filter) autoloading.
Essentially, if you fopen("random://foo") it'll pass that string to an
autoloader that will load and register the stream. It fails if at the end
of the autoloader the stream isn't registered.
Similar for filter and stream_filter_(pre|ap)pend() and loading stream
filters.
- Davey
Okay, so it doesn't deal with namespaced constants, and maybe this is me
being opinionated, but who's going to import constants one by one?
Constants are usually better off grouped together in a class. Although I
don't suppose there's any reason this concept couldn't be expanded to work
for constants as well, for completeness at least - though I have doubts
that very many people would care...Anyways, just spitballing here :-)
I mentioned auto-loading of constants because it would be nice to have
single consistent auto-loading mechanism in PHP for every importable
thing. This currently includes classes, interfaces, traits, functions,
and well constants.
The current composer approach of simply loading the file on every
request regardless of whether you need it ever or not works nicely too.
Related to this, I'd like to see stream (and stream filter) autoloading.
Essentially, if you fopen("random://foo") it'll pass that string to an
autoloader that will load and register the stream. It fails if at the end
of the autoloader the stream isn't registered.Similar for filter and stream_filter_(pre|ap)pend() and loading stream
filters.
- Davey
All resource related stuff is meant to die anyways from what I read and
was told in the past here and on GitHub so I guess this will not come.
--
Richard "Fleshgrinder" Fussenegger
Aren't stream wrappers already lazy-loaded?
e.g. stream_wrapper_register("random", RandomStreamWrapper::class) does not
afaik actually load anything.
Making stream wrappers directly registerable from e.g. "composer.json"
should be a near-trivial thing to implement, and would make them
effectively "autoload" - I imagine it's no more costly to pre-register the
protocol/class-name than e.g. pre-registering some other form of
auto-loader?
Unfortunately, function name resolution has this quirk that class name
resolution doesn't, so something's got to give.I suppose.
Well, then, how about making the feature work consistently for all
functions, by coupling it directly to the "use function" statement?In other words, the feature changes from being strictly about auto-loading
functions, to instead resolving an imported function - so it would be
triggered by the "use function" statement only, rather than by the use of
the function, and the resolved function pertains only to the scope of the
file.A function resolver would simply need to return a callable:
register_function_resolver(function ($name) { if ($name === "html") { return function ($str) { return htmlspecialchars($str, ENT_HTML5); }; } if (substr($name, 0, 5) === "iter\\") { require_once VENDOR_PATH."/nikic/iter/src/bootstrap.php"; return $name; } });This mechanism is probably a lot easier to explain and understand - and
works equally for global or namespaced functions.It also lets you potentially do other weird shit, like overriding
var_dump()or hooking into certain function calls - which could enable you
to do a bunch of evil, but I'm not really big on complicating features
solely to keep users from doing harm; simpler language features tend to
allow you to do more stuff - good or evil.Likely the 99% use-case is simply for Composer to bootstrap your packages
for you, and this feature will permit you to do that.Okay, so it doesn't deal with namespaced constants, and maybe this is me
being opinionated, but who's going to import constants one by one?
Constants are usually better off grouped together in a class. Although I
don't suppose there's any reason this concept couldn't be expanded to work
for constants as well, for completeness at least - though I have doubts
that very many people would care...Anyways, just spitballing here :-)
On Mon, Aug 8, 2016 at 7:54 PM, Rowan Collins rowan.collins@gmail.com
wrote:If not, I don't see why we ever need to be able to autoload global functions. "You want autoloading? Put it in a namespace." Like I say, that leaves the very small edge case of a single namespace spanning multiple files, and an autoloader implementation able to include one of them when a function is called from another.I'm not sure why you would think a single namespace spanning multiple
files is a "very small edge case". I disagree. Here are some libraries
I
am aware of off the top of my head that use functions the same
namespace across multiple files:As well as several of my personal projects. I do not think this is a
"very small edge case."The "iter" example looks a long way from being autoloadable whatever we
supported, but the example of one-function-per-file is definitely
relevant,
so I stand corrected.After a bit of clicking, I even managed to find a line which would fail
to
autoload under the proposed limitation:https://github.com/lstrojny/functional-php/blob/master/src/
Functional/CompareObjectHashOn.phpreturn compare_on($comparison, $keyFunction);
Although interestingly, at the top of the file there is a (technically
unnecessary) "use function Functional\compose;" If there was a "use
function Functional\compare_on;" as well, we'd be fine. (The function
name
would then become qualified at compile time and trigger autoloading at
run
time.)Unless there's a demonstrated, critical performance issue with
auto-loading of global functions, please, let's not cripple this
feature
with inconsistencies from the get-go!Sure, we could try to measure it, but remember that it's not just the
engine code that has the extra cost, it will actually call a userland
function every time you use a global function from inside a namespace if
you don't add a leading "". That userland function will probably do a
bunch of string comparisons before deciding it's not interested, and may
even try to stat a file or two. Those are really expensive operations,
so I
think it's a long way from "micro-optimisation".Unfortunately, function name resolution has this quirk that class name
resolution doesn't, so something's got to give.Regards,
Related to this, I'd like to see stream (and stream filter) autoloading.
Essentially, if you fopen("random://foo") it'll pass that string to an
autoloader that will load and register the stream. It fails if at the end
of the autoloader the stream isn't registered.Similar for filter and stream_filter_(pre|ap)pend() and loading stream
filters.
- Davey
A function resolver would simply need to return a callable:
register_function_resolver(function ($name) {
if ($name === "html") {
return function ($str) {
return htmlspecialchars($str, ENT_HTML5);
};
}if (substr($name, 0, 5) === "iter\\") { require_once VENDOR_PATH."/nikic/iter/src/bootstrap.php"; return $name; } });This mechanism is probably a lot easier to explain and understand -
and works equally for global or namespaced functions.
I don't quite follow what you're suggesting here. When does this
"function resolver" get called? Why does returning a callable rather
than just defining the function help with the problems we've been
discussing?
Okay, so it doesn't deal with namespaced constants, and maybe this is
me being opinionated, but who's going to import constants one by one?
Constants are usually better off grouped together in a class. Although
I don't suppose there's any reason this concept couldn't be expanded
to work for constants as well, for completeness at least - though I
have doubts that very many people would care...
It's not a case of importing constants - or, in most cases, functions -
one by one. As I've mentioned a couple of times, an RFC on static
classes [https://wiki.php.net/rfc/abstract_final_class] and various
similar discussions are frequently met with "you shouldn't be using a
class to group static items, use a namespace instead". For that we need
"namespace autoloading", which in practice means autoloading any of the
items you can put in a namespace. We can already autoload classes, so
that leaves constants and functions.
Regards,
--
Rowan Collins
[IMSoP]
I don't quite follow what you're suggesting here. When does this "function
resolver" get called?
I'm suggesting the use-statement be the trigger, rather than actually
calling the function.
In other words, calls to substr() does not trigger the resolve - a
statement like "use function substr" on the other hand, does.
Why does returning a callable rather than just
defining the function help with the problems we've been discussing?
For some reason, at the time, I thought, this way the function would
indicate whether it resolved a request for "foo\bar" as "foo\bar" or
"bar", but that's probably false... likely the registered function
would get called twice by the engine, first trying for the namespaced,
then if that doesn't resolve, for the global function.
we need "namespace
autoloading", which in practice means autoloading any of the items you can
put in a namespace.
Good point.
So maybe what I'm really proposing is just simply a change to
functionality - so that function and constant references do not
trigger auto-loaders, but instead the "use const" and "use function"
statements do.
I guess this deviates from the way auto-loading works for classes, too
- just in a different way... so maybe it's not much better.
Come to think of it, maybe it's worse, because this would aggressively
trigger auto-loading for functions that might never get called, so,
hmm...
I think, in practice, it's not going to work much differently from the
other proposed work-around though - if only qualified references
trigger auto-loading, then this would trigger auto-loading:
\foo\bar();
And this would too:
use foo\bar;
bar();
But this would not:
bar();
And that could get pretty confusing, since the unqualified call site
looks identical to the qualified call site.
Ugh.
Well, I guess this is what lead to a discussion about a breaking
change to the name resolution rules?
Is there an RFC detailing that idea? Or what was the title of that
discussion? I'd like to read up.
I'm suggesting the use-statement be the trigger, rather than actually
calling the function.In other words, calls to
substr()does not trigger the resolve - a
statement like "use function substr" on the other hand, does.
Ah, I see. The problem with that is, you still have to explicitly list
every function you're going to use, so you might as well just use
require_once, or call "load_function('substr')" directly.
I think, in practice, it's not going to work much differently from the
other proposed work-around though - if only qualified references
trigger auto-loading, then this would trigger auto-loading:\foo\bar();And this would too:
use foo\bar; bar();But this would not:
bar();
Yep, that's about the size of it. If I could go back and time and join
the discussion at the time of PHP 6 / PHP 5.3, I'd argue for simplifying
the name resolution, so the last one was either always the current
namespace or always a global name. Pass me that faster-than-light
telephone... ;)
Regards,
Rowan Collins
[IMSoP]
In other words, calls to
substr()does not trigger the resolve - a
statement like "use function substr" on the other hand, does.Ah, I see. The problem with that is, you still have to explicitly list every
function you're going to use, so you might as well just use require_once, or
call "load_function('substr')" directly.
Well, no - there is still the issue of file names and paths becoming a
dependency, besides issue of having to locate the file in the first
place.
So there is still very much a purpose to this.
Importing all classes with use-statements is good practice anyhow, and
- it forces you to document at the top of your file which elements
you're referencing outside of the local namespace. Of course, that's
opinion, but it's a common opinion - you don't see too much code in
the wild with inline qualified class references, most everyone has a
leading set of use-statements in every file.
Actually, now that I think of it, for that reason, I might actually be
okay with only qualified references triggering auto-loading after all
- this would never become an issue at all, because I'd qualify
everything with use-statements anyhow.
Though I do think it would be somewhat easier to explain this
feature, if it was simply triggered by the use-statement, not by the
circumstance of whether the name is or isn't qualified, because it's
not always obvious from looking at the code - you'd have to look at
the use-statements first and then correlate those with function-calls
and figure it out, every time you look at a file. That mental overhead
is eliminated by just having the use-statement trigger auto-loading.
Also, come to think of it, triggering the auto-loader could still be
deferred, for performance reasons, even if the use-statement is what
triggers is - so it wouldn't aggressively trigger the auto-loader when
the use-statement is encountered, but rather the first time the a
function imported with a use-statement is called. That would be more
consistent with how class resolution works.
I think maybe this could work after all??
Well, no - there is still the issue of file names and paths becoming a
dependency, besides issue of having to locate the file in the first
place.So there is still very much a purpose to this.
Importing all classes with use-statements is good practice anyhow, and
- it forces you to document at the top of your file which elements
you're referencing outside of the local namespace. Of course, that's
opinion, but it's a common opinion - you don't see too much code in
the wild with inline qualified class references, most everyone has a
leading set of use-statements in every file.Actually, now that I think of it, for that reason, I might actually be
okay with only qualified references triggering auto-loading after all
- this would never become an issue at all, because I'd qualify
everything with use-statements anyhow.Though I do think it would be somewhat easier to explain this
feature, if it was simply triggered by the use-statement, not by the
circumstance of whether the name is or isn't qualified, because it's
not always obvious from looking at the code - you'd have to look at
the use-statements first and then correlate those with function-calls
and figure it out, every time you look at a file. That mental overhead
is eliminated by just having the use-statement trigger auto-loading.Also, come to think of it, triggering the auto-loader could still be
deferred, for performance reasons, even if the use-statement is what
triggers is - so it wouldn't aggressively trigger the auto-loader when
the use-statement is encountered, but rather the first time the a
function imported with a use-statement is called. That would be more
consistent with how class resolution works.I think maybe this could work after all??
Having the use statement trigger the auto-loader would result in a lot
of broken code because of optional dependencies (remember the examples I
showed you in the annotation thread).
An alternative approach could be to auto-load only namespaced things and
leave non-namespaced stuff alone. This is in line with PSR-4 (rule 2.1)
and easily implemented if the namespace refactoring into a struct is
performed without any major additional performance hit.
Note that it is trivial to support a flag in the new namespace struct
for C defined namespaced functionality to circumvent the auto-loader.
The introduction of the new namespace struct would require changes to
every bit of PHP C code out there anyways.
Of course this would also mean that the whole story would become a PHP 8
feature.
This would make it even more painful for users to define anything in the
global namespace; a good thing.
It would however encourage people to prefix their stuff inline with a
backslash, otherwise you end up with an endless use chain for every
built-in feature which is not nice. That being said, it's required
anyways if we are really going to introduce namespaces for everything
within PHP (e.g. use function php\random_bytes;). Something I still
think is a bad idea at least for procedural first-level functions.
--
Richard "Fleshgrinder" Fussenegger
An alternative approach could be to auto-load only namespaced things and
leave non-namespaced stuff alone.
It's not quite as simple as that, as examples have already shown.
file a.php
namespace Acme\Foo;
function a() {
return 'Hello World';
}
file b.php
namespace Acme\Foo;
function b() {
$message = a(); # this is a call to Acme\Foo\a
return strpos($message, 'Hello'); # this is a call to \strpos
}
There's no way of telling that the a() is namespaced and the strpos() is
global until after the autoloader has run. There might be a function
Acme\Foo\strpos which is autoloadable.
Regards,
--
Rowan Collins
[IMSoP]
Hi!
Having the use statement trigger the auto-loader would result in a lot
of broken code because of optional dependencies (remember the examples I
showed you in the annotation thread).
I think it's not a good idea in general. use statement right now is
basically a syntax sugar - you just change interpretation of names. But
you don't cause anything to load by this statement. Changing it would
mean people have to change a lot of assumptions about what is loaded
when. E.g., there's a lot of code which use's classes and spaces that
may not even exist - just because they might exist in some scenarios,
and will be used in those scenarios, further down in the code.
I don't think completely changing the semantics of a very widely used
statement is anything we should be doing.
This would make it even more painful for users to define anything in the
global namespace; a good thing.
No it's not. Why should it be a good thing?
It would however encourage people to prefix their stuff inline with a
backslash, otherwise you end up with an endless use chain for every
I'm sorry but this is horrible. PHP code should not look like a fence of
backslashes, backslashes do not have any useful function there and in
99.9999% of cases global functions are global functions, and nobody is
overriding them. Yes, you can override strlen. No, nobody (within
0.00001% accuracy) does.
built-in feature which is not nice. That being said, it's required
anyways if we are really going to introduce namespaces for everything
within PHP (e.g.use function php\random_bytes;). Something I still
think is a bad idea at least for procedural first-level functions.
It's a bad idea for all existing functions and classes. Because it adds
complications for people without giving them anything in exchange.
Stas Malyshev
smalyshev@gmail.com
An alternative approach could be to auto-load only namespaced
things and leave non-namespaced stuff alone.It's not quite as simple as that, as examples have already shown.
file a.php namespace Acme\Foo; function a() { return 'Hello
World'; }
file b.php namespace Acme\Foo; function b() { $message = a();
this is a call to Acme\Foo\a return strpos($message, 'Hello'); # this
is a call to \strpos }There's no way of telling that the a() is namespaced and the
strpos()
is global until after the autoloader has run. There might be a
function Acme\Foo\strpos which is autoloadable.Regards,
Absolutely true yeah. I guess there's nothing to be done about this
without calling the auto-loader all the time plus implementing some caching.
Hi!
Having the use statement trigger the auto-loader would result in a lot
of broken code because of optional dependencies (remember the examples I
showed you in the annotation thread).I think it's not a good idea in general. use statement right now is
basically a syntax sugar - you just change interpretation of names. But
you don't cause anything to load by this statement. Changing it would
mean people have to change a lot of assumptions about what is loaded
when. E.g., there's a lot of code which use's classes and spaces that
may not even exist - just because they might exist in some scenarios,
and will be used in those scenarios, further down in the code.I don't think completely changing the semantics of a very widely used
statement is anything we should be doing.
Ibid.
This would make it even more painful for users to define anything in the
global namespace; a good thing.No it's not. Why should it be a good thing?
Defining anything in the global namespace in userland code is not bad
per se. It just creates potential for name collisions in future PHP
versions if future PHP versions introduce anything that has the same
name. I did not say that we should actively discourage people to define
things in the global namespace, on the contrary since having the ability
to use this is a core part of PHP, but it would make people more
sensible while doing so for their own good. Which is a good thing in my
opinion.
It would however encourage people to prefix their stuff inline with a
backslash, otherwise you end up with an endless use chain for everyI'm sorry but this is horrible. PHP code should not look like a fence of
backslashes, backslashes do not have any useful function there and in
99.9999% of cases global functions are global functions, and nobody is
overriding them. Yes, you can override strlen. No, nobody (within
0.00001% accuracy) does.
I agree completely and I am afraid of the backslash fence as well,
extremely to be honest.
built-in feature which is not nice. That being said, it's required
anyways if we are really going to introduce namespaces for everything
within PHP (e.g.use function php\random_bytes;). Something I still
think is a bad idea at least for procedural first-level functions.It's a bad idea for all existing functions and classes. Because it adds
complications for people without giving them anything in exchange.
Ibid.
--
Richard "Fleshgrinder" Fussenegger
In other words, calls to
substr()does not trigger the resolve - a
statement like "use function substr" on the other hand, does.Ah, I see. The problem with that is, you still have to explicitly list every
function you're going to use, so you might as well just use require_once, or
call "load_function('substr')" directly.
Well, no - there is still the issue of file names and paths becoming a
dependency, besides issue of having to locate the file in the first
place.
Sure, there is a small advantage over raw require statements, because
you're wrapping the file-location logic in a function, which can be a
bit more flexible. But that doesn't actually need the engine to do
anything special:
Proposed:
function autoload_function($name) {
require_once FUNCTION_ROOT . str_replace('', PATH_SEPARATOR,
$name) . '.php';
}
register_function_autoloader('autoload_function');
use function Acme\Util\foo; // calls autoload_function('Acme\Util\foo');
use function Acme\Util\bar; // calls autoload_function('Acme\Util\bar');
Current PHP:
function load_function($name) {
if function_exists($name) return;
require_once FUNCTION_ROOT . str_replace('', PATH_SEPARATOR,
$name) . '.php';
}
load_function('Acme\Util\foo');
load_function('Acme\Util\bar');
All we'd really gain is a standard "name" for load_function (i.e. the
"use" keyword), and I guess a built-in registry for chaining multiple
callbacks together when you run it.
Regards,
--
Rowan Collins
[IMSoP]
If not, I don't see why we ever need to be able to autoload global
functions
Well, for consistency.
For one, if you're refactoring a global function to a namespaced one, this
inconsistency is going to be surprising.
In general, any inconsistency in a language is surprising. Why only
non-global functions can autoload, is going to require a longer
explanation. And that's bad.
If we support auto-loading only for namespaced functions, we're actively
favoring (potentially micro-) performance over consistency.
I use global functions. I know that's not popular, but it's a language
feature, and I use it - for things like test-frameworks and global view
helper-functions.
Single namespace spanning multiple files is also a case for me - that's not
a decision we should make; likely, a PSR and Composer auto-loading features
will drive those decisions. One should have the freedom to add a new
function to an existing namespace, and make that function auto-load, while
packaging that function as a separate optionally-installable package.
I can't see the introduction of arbitrary restrictions or limitations
leading to anything good, language-wise.
Unless there's a demonstrated, critical performance issue with auto-loading
of global functions, please, let's not cripple this feature with
inconsistencies from the get-go!
On Mon, Aug 8, 2016 at 6:46 PM, Rowan Collins rowan.collins@gmail.com
wrote:
I think saying "add a backslash in front of your function names to avoid them being slow" will just lead to lots of "lol wtf php sux".They'll say the same when function and class autoloading don't work the
same way anyway. I think unifying their behavior over time is the best
solution forward. Yes, I'm talking about a BC break eventually, but the
suggestion to autoload only fully qualified function names could buy us
the time to make that BC break less severe.Do you mean eventually changing the name resolution rules for functions to
match those for classes? I wasn't around at the time it was discussed, and
if we were adding them now would be tempted to say the leading \ should
always be mandatory, just like it is for classes. But since we have what we
have, I don't see that big an advantage to changing it.If not, I don't see why we ever need to be able to autoload global
functions. "You want autoloading? Put it in a namespace." Like I say, that
leaves the very small edge case of a single namespace spanning multiple
files, and an autoloader implementation able to include one of them when a
function is called from another.Regards,
Rowan Collins
[IMSoP]
2016-08-08 19:06 GMT+02:00 Rasmus Schultz rasmus@mindplay.dk:
If not, I don't see why we ever need to be able to autoload global
functionsWell, for consistency.
Not only for consistency, but also for things like polyfills, e.g.
random_compat.
Regards, Niklas
For one, if you're refactoring a global function to a namespaced one, this
inconsistency is going to be surprising.In general, any inconsistency in a language is surprising. Why only
non-global functions can autoload, is going to require a longer
explanation. And that's bad.If we support auto-loading only for namespaced functions, we're actively
favoring (potentially micro-) performance over consistency.I use global functions. I know that's not popular, but it's a language
feature, and I use it - for things like test-frameworks and global view
helper-functions.Single namespace spanning multiple files is also a case for me - that's not
a decision we should make; likely, a PSR and Composer auto-loading features
will drive those decisions. One should have the freedom to add a new
function to an existing namespace, and make that function auto-load, while
packaging that function as a separate optionally-installable package.I can't see the introduction of arbitrary restrictions or limitations
leading to anything good, language-wise.Unless there's a demonstrated, critical performance issue with auto-loading
of global functions, please, let's not cripple this feature with
inconsistencies from the get-go!On Mon, Aug 8, 2016 at 6:46 PM, Rowan Collins rowan.collins@gmail.com
wrote:I think saying "add a backslash in front of your function names to avoid them being slow" will just lead to lots of "lol wtf php sux".They'll say the same when function and class autoloading don't work the
same way anyway. I think unifying their behavior over time is the best
solution forward. Yes, I'm talking about a BC break eventually, but the
suggestion to autoload only fully qualified function names could buy us
the time to make that BC break less severe.Do you mean eventually changing the name resolution rules for functions
to
match those for classes? I wasn't around at the time it was discussed,
and
if we were adding them now would be tempted to say the leading \ should
always be mandatory, just like it is for classes. But since we have what
we
have, I don't see that big an advantage to changing it.If not, I don't see why we ever need to be able to autoload global
functions. "You want autoloading? Put it in a namespace." Like I say,
that
leaves the very small edge case of a single namespace spanning multiple
files, and an autoloader implementation able to include one of them when
a
function is called from another.Regards,
Rowan Collins
[IMSoP]
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.
I can understand a little the overwhelming desire to wrap everything in
it's own set of name spaces, but is that REALLY essential to make PHP
'work better'. What is wrong with a simple 'include_once' of the library
you want to use globally across all the code? I have a set of legacy
libraries who's function is not going to change any time soon which
works just the same on old setup's as it does on PHP7. And I see no
reason to even bother with namespace's ... they simply make a lot of
mess for no apparent gain! Where I could see a gain is if those
libraries were simply additional extensions pre-loaded into the engine
rather than something which needs 'auto-loading' at all.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I can understand a little the overwhelming desire to wrap everything in
it's own set of name spaces, but is that REALLY essential to make PHP
'work better'. What is wrong with a simple 'include_once' of the library
you want to use globally across all the code?
Doesn't work with Composer packages, because you can't (and aren't
supposed to) know where a package is installed.
That is, when I'm running the test-suite of my package, the Composer
project is the root folder of that package - but when the package is
being consumed by another project, it's installed in a sub-folder in
that project's "vendor" folder.
The whole point of auto-loading is you don't need to know where things
are installed - a class will simply auto-load, regardless of whether
or not the package is the root project package of the consuming
package. Composer takes care of the bootstrapping.
If we didn't care about that, we wouldn't need auto-loading at all. Or
in other words, your argument works against auto-loading of functions
and classes equally.
What's wrong with a simple require/include statement when you need a
class? Nothing per se. It's horribly inconvenient. The main reason
you're not feeling the same inconvenience when it comes to functions,
is likely because you avoid using them - which is likely because using
functions isn't practical. Likely because they don't auto-load, like
functions. So we use classes as pseudo-namespaces, because they can
auto-load - but that's not what classes are for; you could just as
well argue the language shouldn't have functions at all, then.
In a nut-shell: functions are inconvenient because they don't
auto-load, so we don't use functions, so we don't need auto-loading;
but that's a circular argument.
Of course we need functions to auto-load. For all the same reasons we
need classes to auto-load. Nobody wants to stop and have to figure out
in which file a function is located before they can call it, anymore
than they want to do so for classes. Nobody wants breaking changes in
50 different files because they renamed a file or decided to
split/join some functions across some files.
The auto-loading requirement for functions is the same as for classes.
There's no difference.
Doesn't work with Composer packages, because you can't (and aren't
supposed to) know where a package is installed.That is, when I'm running the test-suite of my package, the Composer
project is the root folder of that package - but when the package is
being consumed by another project, it's installed in a sub-folder in
that project's "vendor" folder.
So Composer IS now the rule rather than some optional extra? It is OK
for users who only want to load the one application, but when one is
running a large number of different packages it's a major hindrance. I
don't need to know where my Linux install has put the include files ...
it takes care of that and then finding the pigging things again is the
problem. Much the same with finding the source of problems in the mess
that composer has created!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
That is, when I'm running the test-suite of my package, the Composer
project is the root folder of that package - but when the package is
being consumed by another project, it's installed in a sub-folder in
that project's "vendor" folder.So Composer IS now the rule rather than some optional extra?
Yes, the community has decided that for us. Or at least, Composer is
a significant player in the ecosystem of PHP development.
require_once() might be fine for NiH applications, but for the
collaborative world of modern PHP, it's the defacto standard.
It is OK
for users who only want to load the one application, but when one is
running a large number of different packages it's a major hindrance.
You'll need to back that up with some more detail. Composer is
specifically designed to compose through multiple packages and also
allows for isolation when that sort of blending doesn't make sense.
Far from a hinderance.
I don't need to know where my Linux install has put the include files ...
it takes care of that and then finding the pigging things again is the
problem.
So, autotools and cmake and the like exist for what purpose then?
Even pkg-config, which was supposed to solve much of this problem is
incomplete, at least on GNU distributions, falls short.
Much the same with finding the source of problems in the mess
that composer has created!
[citation required]
-Sara
That is, when I'm running the test-suite of my package, the Composer
project is the root folder of that package - but when the package is
being consumed by another project, it's installed in a sub-folder in
that project's "vendor" folder.So Composer IS now the rule rather than some optional extra?
Yes, the community has decided that for us. Or at least, Composer is
a significant player in the ecosystem of PHP development.
require_once() might be fine for NiH applications, but for the
collaborative world of modern PHP, it's the defacto standard.
Much as PSR also does.
This is probably fine if one is starting a project from scratch, but
with now 15+ years worth of code that does not follow this 'modern
style' it's another barrier to moving code forward. There is nothing
wrong with the code other than newer users done approve of the style of
working :(
It is OK
for users who only want to load the one application, but when one is
running a large number of different packages it's a major hindrance.You'll need to back that up with some more detail. Composer is
specifically designed to compose through multiple packages and also
allows for isolation when that sort of blending doesn't make sense.
Far from a hinderance.
Several packages that I have been trying to update have said that it's
better NOT to use composer if you need to maintain a legacy view in
addition to the newer code. Certainly having to keep different installs
of PHP with different structures does not help the development process.
It's bad enough running PHP5.4, 5.6 and 7 in parallel without also
changing the framework as well.
I don't need to know where my Linux install has put the include files ...
it takes care of that and then finding the pigging things again is the
problem.So, autotools and cmake and the like exist for what purpose then?
Even pkg-config, which was supposed to solve much of this problem is
incomplete, at least on GNU distributions, falls short.
There is not a 'single solution' that will fit the vast range of users
of PHP but current targeting seems to be aimed at a subset of both
coding style and practice at the expense of perfectly safe and
functional existing code.
Much the same with finding the source of problems in the mess
that composer has created![citation required]
I need to find the write-up on that. It was a well laid out blog on why
pdt/eclipse had problems with the composer approach to managing legacy code.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
So Composer IS now the rule rather than some optional extra?
Yes, the community has decided that for us. Or at least, Composer is
a significant player in the ecosystem of PHP development.
require_once() might be fine for NiH applications, but for the
collaborative world of modern PHP, it's the defacto standard.Much as PSR also does.
This is probably fine if one is starting a project from scratch, but
with now 15+ years worth of code that does not follow this 'modern
style' it's another barrier to moving code forward. There is nothing
wrong with the code other than newer users done approve of the style of
working :(
EVERYTHING is a barrier to moving your code forward. You tell the mailing
this on a regular basis.
Perhaps you should just migrate your 15+ year old code already and be done
with it?
Either that or fork PHP and never upgrade again. If you're this unhappy
with any/all changes to PHP, that seems a viable option.
Regards
Peter
--
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine lester@lsces.co.uk
wrote:So Composer IS now the rule rather than some optional extra?
Yes, the community has decided that for us. Or at least, Composer is
a significant player in the ecosystem of PHP development.
require_once() might be fine for NiH applications, but for the
collaborative world of modern PHP, it's the defacto standard.Much as PSR also does.
This is probably fine if one is starting a project from scratch, but
with now 15+ years worth of code that does not follow this 'modern
style' it's another barrier to moving code forward. There is nothing
wrong with the code other than newer users done approve of the style of
working :(EVERYTHING is a barrier to moving your code forward. You tell the mailing
this on a regular basis.
Perhaps you should just migrate your 15+ year old code already and be done
with it?Either that or fork PHP and never upgrade again. If you're this unhappy
with any/all changes to PHP, that seems a viable option.
Please, let's keep the list clean of ad hominem reactions. Lester has a
valid opinion, based on what seems to be a successful legacy of working
code. That kind of code is essential PHP, and I, for one, value his
perspective and welcome his feedback. If we break his code, or establish
barriers to his code modernization efforts, we're probably doing the same
to a whole class of users whom we might not hear from otherwise.
On Wed, Aug 10, 2016 at 5:37 AM, Peter Lind peter.e.lind@gmail.com
wrote:On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine lester@lsces.co.uk
wrote:So Composer IS now the rule rather than some optional extra?
Yes, the community has decided that for us. Or at least, Composer is
a significant player in the ecosystem of PHP development.
require_once() might be fine for NiH applications, but for the
collaborative world of modern PHP, it's the defacto standard.Much as PSR also does.
This is probably fine if one is starting a project from scratch, but
with now 15+ years worth of code that does not follow this 'modern
style' it's another barrier to moving code forward. There is nothing
wrong with the code other than newer users done approve of the style of
working :(EVERYTHING is a barrier to moving your code forward. You tell the mailing
this on a regular basis.
Perhaps you should just migrate your 15+ year old code already and be
done
with it?Either that or fork PHP and never upgrade again. If you're this unhappy
with any/all changes to PHP, that seems a viable option.Please, let's keep the list clean of ad hominem reactions. Lester has a
valid opinion, based on what seems to be a successful legacy of working
code. That kind of code is essential PHP, and I, for one, value his
perspective and welcome his feedback. If we break his code, or establish
barriers to his code modernization efforts, we're probably doing the same
to a whole class of users whom we might not hear from otherwise.
That was not an ad hominem attack. It was a description of the emails
Lester send to the list.
"Update your code or fork PHP" is not a particularly constructive comment.
Neither, of course, is "don't make changes to my programming language of
choice". Especially given that the feature discussed here would not
actually directly influence Lester - he does not have to use it. In
essence, Lester was arguing against this feature because others in the
community would use it, and that would be a problem for him.
From what i can tell, Lester has an infrastructure problem. Not a PHP
problem. But he still wants to halt language development so the community
doesn't pick up new features that might make problems in his code. That
does not seem reasonable to me.
From what i can tell, Lester has an infrastructure problem. Not a PHP
problem. But he still wants to halt language development so the community
doesn't pick up new features that might make problems in his code. That
does not seem reasonable to me.
Yes I do have an infrastructure problem ... I can't see an easy way to
switch from a traditional PHP model to one based on composer and PSR
rules. Even processing legacy code much of which still uses little
things like 'short tags' into a format that runs cleanly on later
versions of PHP takes time. The scripts I have do a good job, but almost
every site has had several hours bug checking to clear the remaining
missed <?XXX elements and other errors just to make it run clean. With
no changes to what the site actually does ... which is why there is no
urgency to do that work ... and no 'pay' for doing it.
The problem much of the time is that using third party libraries creates
a minefield when those libraries decide now is the time to switch
programming style and re-factor the whole code base. Does one stick with
an older version and maintain that. Which is what I was doing with
ADOdb, or do you re-factor the whole code base to work with the new
style version ... to pick up the changes needed to work with other
developments. Smarty is another key element of my infrastructure and I
have at least four versions running across the system.
The improvement in speed in PHP7 is now working in my code base, but I
don't need any of the overheads of 'strict' mode simply because it's the
wrong solution to the problem of data validation. Exceptions
re-factoring is needed, but the piecemeal way exceptions are being
hacked in is now showing the mistakes made so far, but 'traditional'
code flow does not need exceptions so making them the only error return
in new cases cases problems when they are not catered for in legacy code
moved forward.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi!
EVERYTHING is a barrier to moving your code forward. You tell the mailing
this on a regular basis.
Perhaps you should just migrate your 15+ year old code already and be done
with it?
I would like to note two things here:
-
We have a very diverse community and people have a lot of different
needs and use cases. It is inevitable that some of these needs would be
radically different from yours. Reacting with hostility to expressing
such needs is not helping anybody. Anything of substance can be said in
a neutral or cooperative tone. Let's strive for it. -
Old code is literally 100% of code run on PHP now, with regard to 7.1
or any next.next version. Every application deployed is old code. And
due to PHP's by now venerable history - yes, some of this code is very
old, sometimes originating in PHP 4 code bases and beyond. This does not
mean we have to be bound forever by it, but this also does not mean we
should be dismissive about it and ignore it completely.
As I said many times - and will say many times in the future,
undoubtedly, until it improves - our adoption numbers for latest
versions is nothing to be proud of. It is a problem we need to be aware
of. If we design tons of new and shiny features and 0.0001% of the
community ends up using them, it's not worth wasting the time IMHO.
So in my opinion we should not be callous about the "never upgrade"
option - because right now it's what a very sizeable part of the
community already doing, and IMO this is our problem, not theirs.
Stas Malyshev
smalyshev@gmail.com
So in my opinion we should not be callous about the "never upgrade"
option - because right now it's what a very sizeable part of the
community already doing, and IMO this is our problem, not theirs.
I set up http://phpsurgery.org/ a few years back with every intention of
adding content and tools to help with the upgrade process for users who
in many cases do not know they are even running their sites on PHP :(
If people have suitable material to help populate it then please feel
free to forward it or contact me off list to set up a account. At some
point I'll being THAT site up to the latest versions ... it's on a
PHP5.4 base at the moment.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
There is not a 'single solution' that will fit the vast range of users
of PHP but current targeting seems to be aimed at a subset of both
coding style and practice at the expense of perfectly safe and
functional existing code.
This entire thread is about trying to find ways for a new feature not
to be "at the expense of" anything. If you don't want autoloading,
that's fine. It was fine in 2004 when PHP 5 first allowed it; it was
fine in 2009 when PHP 5.3 introduced namespaces; and it will be fine in
2017 even if we add something new to PHP 7.2.
Perhaps rather than complaining that people are focussing on the "wrong"
improvements to the language, you could come up with some
well-thought-out suggestions of things you would like to see added.
Regards,
Rowan Collins
[IMSoP]
@Peter and @Rowan: Very good point and sounds reasonable, I also thing
there is need for evolution. Idea of fork PHP and never update made me
laugh to tears :)
2016-08-10 11:42 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
There is not a 'single solution' that will fit the vast range of users
of PHP but current targeting seems to be aimed at a subset of both
coding style and practice at the expense of perfectly safe and
functional existing code.This entire thread is about trying to find ways for a new feature not to
be "at the expense of" anything. If you don't want autoloading, that's
fine. It was fine in 2004 when PHP 5 first allowed it; it was fine in 2009
when PHP 5.3 introduced namespaces; and it will be fine in 2017 even if we
add something new to PHP 7.2.Perhaps rather than complaining that people are focussing on the "wrong"
improvements to the language, you could come up with some well-thought-out
suggestions of things you would like to see added.Regards,
Rowan Collins
[IMSoP]--
--
pozdrawiam
Michał Brzuchalski
@Peter and @Rowan: Very good point and sounds reasonable, I also thing
there is need for evolution. Idea of fork PHP and never update made me
laugh to tears :)
To be quite honest ... I do now wish that I had simply forked PHP5.3 and
maintained that with security fixes, although the ISP's who still
support that have done a reasonable job. I decided that it was better to
pull everybody over to PHP5.4 and so all the older services could be
shut down, but it is not a 5 minute job transferring a legacy site and
there are still a large number left to resolve.
More irritating is that I have a framework that I've moved everything
onto so as to loose the the legacy problems altogether, but while it
runs perfectly cleanly on PHP7, it is not written in a style that allows
things like 'namespace' to be integrated. Some of the libraries ARE
being reworked in a manor that 'modernises' them, but most definitely
breaks compatibility with existing code. Things like moving from Smarty
2 to Smarty 3 and then loosing the compatibility wrapper took months,
but now the new 'loader' for Smarty 3 is clashing with the legacy Smarty
based projects and it is that sort of hassle that simply crushes any
pleasure in coding these days, when there is nothing gained by this move
to 'auto-loading' libraries as the standard for everybody.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk