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 e
On 8/7/2016 1:19 PM, Rasmus Schultz wrote:
> 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 "Fleshgri
On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz 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
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
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(...)
On Sun, Aug 7, 2016 at 12:32 PM, David Rodrigues
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 autoloa
On 07/08/2016 23:42, Davey Shafik 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.
On Mon, Aug 8, 2016 at 12:51 PM, Rowan Collins
wrote:
> On 07/08/2016 23:42, Davey Shafik 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,
>
>
> 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
> autolo
On 08/08/2016 15:36, Levi Morrison wrote:
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
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
>
> 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 for
2016-08-08 18:00 GMT+02:00 Levi Morrison :
> >
> > 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 u
On 08/08/2016 17:00, Levi Morrison 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 thei
On 08/08/2016 17:23, Niklas Keller wrote:
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 requ
>
> 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
> 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
On 08/08/2016 18:03, Levi Morrison 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
2016-08-08 19:06 GMT+02:00 Rasmus Schultz :
> > If not, I don't see why we ever need to be able to autoload global
> functions
>
> Well, 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 globa
> 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 c
On Mon, Aug 8, 2016 at 1:15 PM, Rasmus Schultz wrote:
> > 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 dire
On 8/8/2016 10:23 PM, Davey Shafik wrote:
> On Mon, Aug 8, 2016 at 1:15 PM, Rasmus Schultz wrote:
>> 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 i
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
On 07/08/16 12:19, Rasmus Schultz wrote:
> 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 co
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 to strpos() triggers the auto-loader?
I think triggering it even o
On Mon, Aug 8, 2016 at 10:54 PM, Lester Caine wrote:
> 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 global
On 08/08/2016 21:15, Rasmus Schultz wrote:
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);
};
On 08/08/16 22:59, Rasmus Schultz wrote:
> 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 packa
On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine wrote:
>> 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" fol
On Tue, Aug 9, 2016 at 12:04 AM, Rowan Collins wrote:
> 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 trigg
On 09/08/2016 17:05, Rasmus Schultz wrote:
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 th
On Tue, Aug 9, 2016 at 6:17 PM, Rowan Collins wrote:
>> 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 u
On 8/9/2016 7:44 PM, Rasmus Schultz wrote:
> 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 go
On 09/08/2016 21:26, Fleshgrinder wrote:
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';
}
# f
On 09/08/2016 18:44, Rasmus Schultz wrote:
On Tue, Aug 9, 2016 at 6:17 PM, Rowan Collins wrote:
>>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 explic
On 09/08/16 06:54, Sara Golemon wrote:
> On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine wrote:
>>> 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
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 c
On 10 August 2016 at 10:51, Lester Caine wrote:
> On 09/08/16 06:54, Sara Golemon wrote:
> > On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine 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
On 10/08/2016 09:51, Lester Caine wrote:
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
@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 :
> On 10/08/2016 09:51, Lester Caine wrote:
>
>> There is not a 'single solution' that will fit
On 10/08/16 12:14, Michał Brzuchalski wrote:
> @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 tha
On Wed, Aug 10, 2016 at 5:37 AM, Peter Lind wrote:
> On 10 August 2016 at 10:51, Lester Caine wrote:
>
> > On 09/08/16 06:54, Sara Golemon wrote:
> > > On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine
> wrote:
> > >> So Composer IS now the rule rather than some optional extra?
> > >>
> > > Yes, the
> On 09/08/2016 21:26, Fleshgrinder wrote:
>> 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
> Wor
On 10 Aug 2016 19:05, "Bishop Bettini" wrote:
>
> On Wed, Aug 10, 2016 at 5:37 AM, Peter Lind
wrote:
>>
>> On 10 August 2016 at 10:51, Lester Caine wrote:
>>
>> > On 09/08/16 06:54, Sara Golemon wrote:
>> > > On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine
wrote:
>> > >> So Composer IS now the rul
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:
1. We have a very diverse community and people have a lot of di
On 10/08/16 20:36, Peter Lind wrote:
>>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
On 10/08/16 20:55, Stanislav Malyshev wrote:
> 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
47 matches
Mail list logo
