Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] BC break with rand() where min > max

What is the sense to use min > max, in general? It should 'flip' arguments automatically in this case? 2016-08-08 18:36 GMT-03:00 Leigh : > Hi all, > > There has been an unforeseen break with rand() when the minimum value is > greater than the maximum. > > Prior to 7.1 rand()

Re: [PHP-DEV] BC break with rand() where min > max

Leigh, I would _very_ much prefer to keep this BC. If we do the right thing, and there are no repercussions, I'd actually remove the warning. If you think we might want to disallow this in the future, use an E_DEPRECATED, but a warning seems pointless unless it's doing the wrong thing, or it's

Re: [PHP-DEV] Function auto-loading

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); };

Re: [PHP-DEV] Function auto-loading

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 >

Re: [PHP-DEV] Function auto-loading

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

[PHP-DEV] BC break with rand() where min > max

Hi all, There has been an unforeseen break with rand() when the minimum value is greater than the maximum. Prior to 7.1 rand() would happily accept backwards parameters and return a value, however in the 7.1 branch it now emits a warning and returns false. I've preemptively committed a fix to

[PHP-DEV] SQLite 3.14

Hi! SQLite 3.14 has been released today. It brings some improvements and new features, and fixes a few bugs, see . I think PHP-7.1 should be updated, but I'm not sure about PHP-7.0, even though I found no regression when running the sqlite3 and

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] Function auto-loading

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 >

Re: [PHP-DEV] Function auto-loading

> 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

Re: [PHP-DEV] Function auto-loading

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

[PHP-DEV] VCS Account Request: smarijic

I would like to contribute on maintaining PHP. Creating RFC-s etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] RFC - Immutable classes

@Fleshgrinder thanks, my knowledge of C allowed me to implement some features experimentally. When problem occurs then I'll find any needed help because I think this feature is needed. Personally I don't have wiki karma so help in writing RFC if you have karma could help us very much. 2016-08-08

[PHP-DEV] Re: [RFC][DISCUSSION] Argon2 Password Hash

> > Argon2 also supports keyed hashes and associated data, but seen no > mention of either. > Jared Hi Jared, This is a design decision to prevent changing the PHP API. The Argon2 reference library exposes two ways of working with Argon2 hashes, we can either use the Argon2_Context struct, or

Re: [PHP-DEV] RFC - Immutable classes

@Fleshgrinder, Thanks, every help is welcome. 2016-08-08 18:44 GMT+02:00 Fleshgrinder : > On 8/8/2016 5:00 PM, Silvio Marijić wrote: > > It's great that you are up of this. > > I think it will be great to see this one in action. > > > > I agree that we should separate them

Re: [PHP-DEV] Function auto-loading

> 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

Re: [PHP-DEV] Function auto-loading

> > 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

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] RFC - Immutable classes

On 8/8/2016 5:00 PM, Silvio Marijić wrote: > It's great that you are up of this. > I think it will be great to see this one in action. > > I agree that we should separate them into separate RFC-s. > > 2016-08-08 15:51 GMT+02:00 Michał Brzuchalski : > >> It is great to

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] Function auto-loading

> > 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

Re: [PHP-DEV] [RFC] E_NOTICE for invalid array container

All, I updated the RFC, and made a couple updates to tests where this notice is raising itself (fpm & mysqli). I ended up catching a couple of oddities in how mine (and previous proposed) changes would have impacted a foreach(list() = each()), so it won't raise a warning on the last, null,

[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

Hi Yasuo! On 25.07.2016 at 11:49, Yasuo Ohgaki wrote: > Due to defects in the RFC, vote is reopened and restarted. > Followings are changes from 1st vote. > > […] > > Vote ends 2016/08/02 23:59:59 UTC. I've just noticed that the voting is still open, although it's already 2016-08-08. Shouldn't

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] RFC - Immutable classes

It's great that you are up of this. I think it will be great to see this one in action. I agree that we should separate them into separate RFC-s. 2016-08-08 15:51 GMT+02:00 Michał Brzuchalski : > It is great to hear somone is interested so why not. My lately discussion >

Re: [PHP-DEV] Function auto-loading

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

Re: [PHP-DEV] Function auto-loading

> > > 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 >

Re: [PHP-DEV] RFC - Immutable classes

It is great to hear somone is interested so why not. My lately discussion found usefull implementing 3 keywords, such as: 1. *immutable* for the functionality you are currently working on. 2. *sealed* for the above plus type not changeable. 3. *final* for the above plus not being overridable. But

Re: [PHP-DEV] RFC - Immutable classes

@Michal Would you consider cooperating on implementing immutable and sealed modifiers? 2016-08-08 15:20 GMT+02:00 Michał Brzuchalski : > @Silvio I've tried to implement final https://github.com/php/ > php-src/compare/master...brzuchal:final-properties but haven't found

Re: [PHP-DEV] RFC - Immutable classes

@Silvio I've tried to implement final https://github.com/php/php-src/compare/master...brzuchal:final-properties but haven't found time to implement immutable and sealed, AFAIK I had problems with OPcache enabled, you need to remember to run every test after compile with opcache enabled in CLI.

Re: [PHP-DEV] RFC - Immutable classes

@Michal, well no I did read it. I see that there is not much going on there since last year. Did you tried to implement it ? 2016-08-08 14:49 GMT+02:00 Michał Brzuchalski : > > 2016-08-08 14:47 GMT+02:00 S.A.N : > >> May be better to do as immutable

Re: [PHP-DEV] RFC - Immutable classes

2016-08-08 14:47 GMT+02:00 S.A.N : > May be better to do as immutable arrays? > > const = new Email; > > it will be a super global immutable instance of Email. > I think you've missunderstood concept of immutable classes. -- pozdrawiam -- Michał Brzuchalski

Re: [PHP-DEV] RFC - Immutable classes

May be better to do as immutable arrays? const EmailObject = new Email; It will be a super global immutable instance of Email. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Immutable classes

May be better to do as immutable arrays? const = new Email; it will be a super global immutable instance of Email. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Immutable classes

Sure my final properties was first thought, lately in discuccion it turns into immutable, sealed and final see here https://marc.info/?l=php-internals=146005058530881=2 Have you also read about Immutable modifier from last year? http://marc.info/?t=14476653941=1=2 it's exactly about immutable

Re: [PHP-DEV] RFC - Immutable classes

Btw, I was not aware that there was already conversation on immutable classes. 2016-08-08 14:31 GMT+02:00 Silvio Marijić : > I see your standpoint, but I think it could cause confusion because of > final classes. I think "immutable" is more suited here. > What I try to

Re: [PHP-DEV] RFC - Immutable classes

I see your standpoint, but I think it could cause confusion because of final classes. I think "immutable" is more suited here. What I try to achieve is something similar like case classes in Scala. Best regards, 2016-08-08 13:16 GMT+02:00 Michał Brzuchalski : > Hi

Re: [PHP-DEV] Function auto-loading

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

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-08-08

Results for project PHP master, build date 2016-08-08 06:27:02+03:00 commit: dbf63cb previous commit:65b6f20 revision date: 2016-08-08 01:47:05+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] RFC - Immutable classes

Hi Silvio, Look into my talk about final properties https://marc.info/? t=14597925583=1=2 maybe there would be something usefull. There is also talk about mutable and immutable properties and other class modifiers also about var and val. I'm not sure that it should be class midifier rather

[PHP-DEV] Namespaces internal refactoring

Hi internals, I would like to present my idea for namespaces refactoring and provide an RFC for them. Currently in PHP namespaces are implemented as a prefix of class or function name. Using ReflectionClass or ReflectionFunction we can retrieve class/function name and its namespace-name. In both

Re: [PHP-DEV] Adding validate_var_array()/validate_input_array() to which version?

Hi Niklas and Davey, On Mon, Aug 8, 2016 at 7:23 PM, Niklas Keller wrote: > 2016-08-08 12:03 GMT+02:00 Yasuo Ohgaki : >> >> Hi Darvey, >> >> On Mon, Aug 8, 2016 at 4:24 PM, Niklas Keller wrote: >> >> I made choices for targeted version,

Re: [PHP-DEV] Function auto-loading

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.

[PHP-DEV] RFC - Immutable classes

Hi, I would need your help with one idea. I'm working on one RFC that I'm would like to submit. Idea is that after you initialize object eg. after constructor returns, object would be locked, and you wouldn't be able to change properties on that object anymore. It would like this: public

Re: [PHP-DEV] Adding validate_var_array()/validate_input_array() to which version?

2016-08-08 12:03 GMT+02:00 Yasuo Ohgaki : > Hi Darvey, > > On Mon, Aug 8, 2016 at 4:24 PM, Niklas Keller wrote: > >> I made choices for targeted version, 7.1.0 or 7.2.0 > > > > Feature freeze has been beta1. If the RM says it's too late, we don't > need a >

Re: [PHP-DEV] Adding validate_var_array()/validate_input_array() to which version?

Hi Darvey, On Mon, Aug 8, 2016 at 4:24 PM, Niklas Keller wrote: >> I made choices for targeted version, 7.1.0 or 7.2.0 > > Feature freeze has been beta1. If the RM says it's too late, we don't need a > vote. It's too late. Niklas is right. I might be too late for 7.1.

Re: [PHP-DEV] Adding validate_var_array()/validate_input_array() to which version?

2016-08-08 0:20 GMT+02:00 Yasuo Ohgaki : > Hi Pierre, Niklas > > On Sun, Aug 7, 2016 at 9:20 PM, Pierre Joye wrote: > > I would not rush it into 7.1. > On Mon, Aug 8, 2016 at 12:20 AM, Niklas Keller wrote: > > Isn't it a bit late to