Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi Rowan,
On Fri, Mar 20, 2015 at 7:12 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 19/03/2015 20:50, Yasuo Ohgaki wrote:
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com mailto:sbj.ml.r...@gmail.com wrote:
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net
mailto:yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would you write an callback containing an already
constructed object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
I'm not proposing deprecate it soon, but in the long run.
It will need a decade to deprecate it.
It is not time that is needed, but an alternative way of expressing use
this instance method as a callback, such as those discussed elsewhere in
the thread.
I replied how it could be deprecated.
I'm not commenting for it, but the deprecation discussion.
You cannot restrict discussion to what you would want, can it?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?
On Fri, Mar 20, 2015 at 7:26 AM, Eric Stenson erics...@microsoft.com wrote: PHP Internals folks-- We're doing some performance work in WinCache, and we're finding that some frameworks are...uh...enthusiastically using file_exists(), is_file() and is_dir() functions on files/directories that don't exist. Every. Single. Pageload. Does the PHP stat cache include negative cache entries? If not, why not? Are there any existing extensions that implement a negative cache for file_exists(), is_file(), et. al.? I suppose you mean to cache what does not exist? I think it is somehow done, indirectly or this info could be detected using the stat cache and the resolved path cache. However it may make this part of the cache implementation a bit more trickier but it should be possible. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
On 19/03/2015 22:43, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Mar 20, 2015 at 7:12 AM, Rowan Collins
rowan.coll...@gmail.com mailto:rowan.coll...@gmail.com wrote:
On 19/03/2015 20:50, Yasuo Ohgaki wrote:
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com mailto:sbj.ml.r...@gmail.com
mailto:sbj.ml.r...@gmail.com mailto:sbj.ml.r...@gmail.com
wrote:
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki
yohg...@ohgaki.net mailto:yohg...@ohgaki.net
mailto:yohg...@ohgaki.net mailto:yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long
run. IMHO.
Then how would you write an callback containing an already
constructed object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
I'm not proposing deprecate it soon, but in the long run.
It will need a decade to deprecate it.
It is not time that is needed, but an alternative way of
expressing use this instance method as a callback, such as those
discussed elsewhere in the thread.
I replied how it could be deprecated.
I'm not commenting for it, but the deprecation discussion.
You cannot restrict discussion to what you would want, can it?
I had no intention of restricting the discussion in any way, apologies
if it came across that way.
Perhaps what I should have said is it is not *only* time that is needed
- we need to design the replacement before it's worth even thinking
about deprecating something.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 19/03/2015 20:49, Alex Bowers wrote: My proposal is something similar to Pythons slice, in PHP this would look like: $slided = $array[1:4] This will get the elements in positions 1,2,3,4. (1 through 4 inclusive), ignoring the actual key of the array. The result for an array will be an array with the keys preserved, in the same order. While I can see the reasoning for not looking into the actual keys (which might not have a logically sliceable order), I think the syntax needs to be more distinct, because this seems a bit confusing: $countdown = [ 5 = 'Five!', 4 = 'Four!', 3 = 'Three!', 2 = 'Two!', 1 = 'One!', 0 = 'Zero!' ] $countdown[0]; // 'Zero!' $countdown[0:0]; // ['Five!'] $countdown[0:][0] // 'Zero!' $countdown[:0][0] // null - slice contains no key 0 The problem is that the slice access looks like an extension of key access, but is actually a new concept of positional element access. With a slight tweak to syntax, such as adding an @, we could make positional access available for non-slices as well: reset($countdown); // Five! - a common way of getting the first element positionally $countdown[@0]; // 'Five!' $countdown[@1]; // 'Four!' $countdown[@0:0] // ['Five!'] $countdown[@0:1] // ['Five!', 'Four!'] $countdown[@0:][@0] // 'Five!' $countdown[@:0][@0] // 'Five!' A side addition, that may be considered is adding [-1] to get the last item in the array. But that is not a main part of this RFC. This would actually be a really important addition for me, but only if I can do it on a non-slice, as above: $countdown[-1]; // null - no such key end($countdown); // 'Zero!' - common way of getting last element $countdown[@-1]; // 'Zero!' - positional access counting from the end $countdown[@-2]; // 'One!' - fiddly to do in current PHP I just wrote out all those examples and realised that it may not be possible to reuse @ in this context. Finding new symbols to use for syntax is hard. :( Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Fri, Mar 20, 2015 at 5:04 AM, Nikita Popov nikita@gmail.com wrote: On Thu, Mar 19, 2015 at 6:49 PM, Zeev Suraski z...@zend.com wrote: On 19 במרץ 2015, at 19:40, Dan Ackroyd dan...@basereality.com wrote: You are being dumb here as well. We try to avoid breaking code in point releases. This BC break can only be done at a major version. Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase. I don't think this is true. There is no requirement for us to deprecate something before we remove it. Deprecation is a courtesy to our users in cases where a heavily used feature is being dropped. I think we do not need to argue about the impact of having something generating a fatal error all of a sudden in 7.1. Or am I missing something? :) Realistically most people consider E_NOTICE to be a higher error level than E_DEPRECATED. If somebody is willing to suppress the notices this currently generates, chances are very high that deprecations are suppressed as well. I don't see any release process issues with dropping this without deprecation. (But I'm still -1 on the change, because I don't see why we'd suddenly want to change this one relatively unimportant notice to be fatal while leaving everything else alone.) Same, if anything doing fatal then it has to be done in 7.0. Also I have to agree with Zeev on that, a warning or deprecation notice should be enough. I know it is not what many users want, to clean up such things, but we decided not to have a 5.7 to prepare such removals, let act accordingly. cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 19/03/2015 23:55, Alex Bowers wrote: Thats a good point, something else that just came to me; your example of $countdown[0:0]; if we had it as inclusive indexes, then this would actually give you ['Five!', 'Five!'], which is unlikely to be what was desired. I'm not sure why it would duplicate the item like that. My interpretation of $array[$start:$end] would be an array containing all those elements of $array with a position more than or equal to $start, but less than or equal to $end ($position = $start $position = $end). Under that interpretation, $array[0:0] is a valid slice, of length 1, which would contain only the element of $array with position 0 (0 = 0 0 = 0). Since you propose to preserve keys in the slice, it's actually impossible to have a duplicate item in the output anyway: if you were right and it selected the first item twice, you'd get [5 = 'Five!', 5 = 'Five!'], but keys are unique by definition, so it would end up stored as [5 = 'Five!']. 1) The range cannot be 0 in length (such that, from - to must be 0) - This would also get around issues of people trying to use it like so : $countdown[5:3], as the expected outcome of that should be a fatal error. $countdown[0:0] is a slice of length 1, not 0, just as $countdown[0:1] is a slice of length 2, not 1. Under my proposed definition, $countdown[5:3] could simply always return an empty array, since there is no value of $position such that ($position = 5 $position = 3). Also, your use-case of 0:0 would be better placed simply using $countdown[0]. Check my example again. $countdown[0] refers to the element with key 0, so is absolutely not a replacement for $countdown[0:0]. This is the whole point of my example. I think the use of the @ symbol would be misplaced for this To be clear, @ was just the first idea that came to mind, not central to my point. The point is to first create syntax for positional access, and then extend that to positional slice access. A different symbol is certainly a possibility; but this is something that happens nowhere else (ignoring the by reference) in PHP, and feels like it isn't the best solution to the problem. I'm not sure what you mean by something that happens nowhere else PHP has syntax for all sorts of things, using all sorts of symbols. Your own suggestion uses the : symbol in a place where it currently can't exist. Other languages that implement this do not require a prefixed symbol, and I don't see the need for PHP to have one. Most languages don't need to worry about an array type which has keys independent from their position. PHP is the only language I know where the 0 in $foo[0] does not refer to the position in the array, but a key which can appear at any position. 2) Would a possible solution to this be just to make it explicitly clear in the documentation that this *does not* refer to the keys, and instead the array positions? To my mind, no. Manual pages about syntax features are hard to find unless you know exactly what that syntax feature is called, and documenting an inconsistency is no substitute for avoiding that inconsistency in the first place. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
On 19/03/2015 20:50, Yasuo Ohgaki wrote:
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com mailto:sbj.ml.r...@gmail.com wrote:
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net
mailto:yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would you write an callback containing an already
constructed object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
I'm not proposing deprecate it soon, but in the long run.
It will need a decade to deprecate it.
It is not time that is needed, but an alternative way of expressing use
this instance method as a callback, such as those discussed elsewhere
in the thread.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi Rowan, On Fri, Mar 20, 2015 at 8:00 AM, Rowan Collins rowan.coll...@gmail.com wrote: I had no intention of restricting the discussion in any way, apologies if it came across that way. Perhaps what I should have said is it is not *only* time that is needed - we need to design the replacement before it's worth even thinking about deprecating something. Deprecation is future scope that may be years later if it may. I fully agree. I would like to fix this bug now. Current behavior is very annoying... Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data
Hi all, On Sun, Mar 1, 2015 at 1:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: There are too many things that I would like to improve ;) https://bugs.php.net/bug.php?id=69127 This bug is known fatal bug for session module. I proposed lazy_destroy to fix this before, but it declined. I think the name was wrong. With the proposal, session module destories session data with lazy manner, but it's actually precise manner. i.e. Session module and browser is _not_ synced, so destroy must be done async manner (~= lazy manner. For example, delete session data 60 seconds later). The reason why session_regenerate_id(true) fails is it deletes session data immediately even if session and browser is not in sync. Session and browser cannot sync because there is no means in HTTP/Cookie. Is there any other better idea for this? I've updated old RFC for this bug fix. https://wiki.php.net/rfc/session_regenerate_id I would like to start discussion shortly. If anyone would like to comment now, I appreciate it. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi Zeev, On Wed, Mar 18, 2015 at 6:43 PM, Zeev Suraski z...@zend.com wrote: FWIW, as someone who did play with the patch (both patches, of course), I'm not sure why people are claiming you don't understand the RFC. Your comments in the code are 100% accurate, which means you understood exactly how it works. Josh Di Fabio just pointed out to me that the code in question wasn't actually written by you but by Dennis Birkholz, so my statement was incorrect. Still, from what you said it appears to me you still understood the behavior but disagreed with it. I know that at least on my end, that was definitely the case. Yes and I fully agree. Anyway, unlike your proposal, I have to advocate users not to use type hint for database INT8, JSON numeric, etc. It will be tough job... Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi all, On Thu, Mar 19, 2015 at 6:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Wed, Mar 18, 2015 at 6:43 PM, Zeev Suraski z...@zend.com wrote: FWIW, as someone who did play with the patch (both patches, of course), I'm not sure why people are claiming you don't understand the RFC. Your comments in the code are 100% accurate, which means you understood exactly how it works. Josh Di Fabio just pointed out to me that the code in question wasn't actually written by you but by Dennis Birkholz, so my statement was incorrect. Still, from what you said it appears to me you still understood the behavior but disagreed with it. I know that at least on my end, that was definitely the case. Yes and I fully agree. Anyway, unlike your proposal, I have to advocate users not to use type hint for database INT8, JSON numeric, etc. It will be tough job... Anyone who are willing to use type hint for any data that has integer/float form, you still have chance to vote to 'yes' for https://wiki.php.net/rfc/coercive_sth Weak mode can be coercive. Coercive mode works better with my type affinity proposal also. https://wiki.php.net/rfc/introduce-type-affinity Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] new wiki account / requesting RFC karma
Dear internals, I just registered my own php.net account, username bof. This is the obligatory introduction mail I'm supposed to send :) TL;DR: I think I know what I'm doing, and currently I'm requesting RFC karma. I'm mainly working as a system administrator. As part of my job I'm supporting a small group of PHP developers, and the deployed, operational result of their work. I've been building PHP myself for development and production, starting with late 5.4 releases, and I'm now tracking 5.6.X pretty closely. I've been subscribed to internals for some time now, following most of the discussions and sometimes dropping an opinion. Apart from system administration itself I'm a programmer at heart, using C since the early 90ies. No biggie open source contributions to point at, but I've been working with everything from kernel code to server application code the last 20 years; regarding PHP itself, I contributed to one, and authored another nearly unused extension (but we're using them in production), which you can find at https://github.com/bof, I internally developed a third one that we don't publish, made some bug reports, the most recent one, fixed by laruence for 5.6.7, was #69038 The present reason to apply for an account is that working on another current bug report, #68486, I came to look pretty closely at the apache2handler code. I got the feeling that at the moment, nobody gives it the love it deserves, and I want to step up and change that. So my mid-term goal is to offer my help as maintainer of that part of the codebase, if I'm deemed worthy :) For a start, apart from nagging to get that bug closed, I will work on fixing the currently broken virtual() function (new bug report coming soon...), and as already mentioned in a recent internals thread (PHP apache2handler virtual() function) I'm working on a new apache specific function apache_tail_request() - and that' where my present request for an account comes from, because I think that I'll need to provide a small RFC regarding that addition. Hope this is sufficient introduction for now. If not, just ask. best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi all, On Sun, Mar 15, 2015 at 7:15 PM, Nicolas Grekas nicolas.grekas+...@gmail.com wrote: Foo::bar(); // OK ['Foo', 'bar'](); // OK 'Foo::bar'(); // FATAL ERROR Hi, does this topic need to be addressed before PHP7 goes feature freeze? Or is it a bugfix? (Julien already provided a patch) I'm not familiar with writing RFCs. I fear I won't be able to handle it on schedule if one is required. Can someone help please? It's nice if this bug could be fixed by PHP7. Distinguishing array and callable is problematic. Array callable is better to be deprecated in the long run. IMHO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
Hey, Le dim. 15 mars 2015 à 01:54, Niklas Keller m...@kelunik.com a écrit : Morning, I'd like to announce that I'll open the vote for the in operator later that day. You can find the RFC here: https://wiki.php.net/rfc/in_operator There was a small change: If the haystack is a string, integers are no longer allowed as needle. This change was necessary so it's consistently strict for both, array and string haystacks. Regards, Niklas If there is one thing that can be improved in a related area: create a true Set datatype. You just don't imagine how often I encountered bottlenecks in PHP application where in_array() was used (thousands times per request over not so small arrays). Sometimes it can be improved by storing the value in the key part (using an array to emulate a hash thanks to the internal implementation of arrays), using SplObjectStorage in case of objects or even a bloom filter implementation [1]. Visit [2] for some inspirations. As you see , there is room for improvement to make things easier, but that wouldn't be by simply be achieved by adding an in keyword. Everytime I see an in_array(), I also cry, but not because of the syntax, rather because I know how it operates (think: full table scan if you were doing a SELECT query without proper indexes). This simply cannot be improved in a proper way without a true Set implementation. [1] http://pecl.php.net/package/bloomy [2] http://technosophos.com/2009/05/29/set-objects-php-arrays-vs-splobjectstorage.html Cheers, Patrick
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi,
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would you write an callback containing an already constructed object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Fri, Mar 20, 2015 at 1:21 PM, François Laupretre franc...@php.net wrote: May I also add that it is not the first time people raise concerns about RFCs when vote starts. On different occasions, it was clear that most had not read the RFC before the vote was announced. I even have two RFCs which were planned for 7.0 and won't be in because I had to stop the vote and restart a discussion. When we have short timelines, as for 7.0, it's a real problem because restarting a discussion easily adds one month to the approval process. Actually, I don't know if, in this case, I shouldn't reply that the discussion is over and that it's just too late to wake up. The problem is not the RFC process but us accepting idealistic timelnes. It is why I did not vote (for the ones that did not respect the RFC process) or no for the ones I totally disagree with. But this is off topic imho, we took these decisions now we have to work with that. In any case, one thing has to end, the playing with the rules. Discussions must happen for at least two weeks before a RFC goes to vote, mail must be sent to announce each phase. And last but not least, editing a RFC during or after the votes in a way that it changes what people votes for or against is not something I want to see. We have to solve this issue. Learning by doing :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates awarning and loses session data
Yasuo Ohgaki wrote: On Sun, Mar 1, 2015 at 1:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: There are too many things that I would like to improve ;) https://bugs.php.net/bug.php?id=69127 This bug is known fatal bug for session module. I proposed lazy_destroy to fix this before, but it declined. I think the name was wrong. With the proposal, session module destories session data with lazy manner, but it's actually precise manner. i.e. Session module and browser is _not_ synced, so destroy must be done async manner (~= lazy manner. For example, delete session data 60 seconds later). The reason why session_regenerate_id(true) fails is it deletes session data immediately even if session and browser is not in sync. Session and browser cannot sync because there is no means in HTTP/Cookie. Is there any other better idea for this? I've updated old RFC for this bug fix. https://wiki.php.net/rfc/session_regenerate_id I would like to start discussion shortly. If anyone would like to comment now, I appreciate it. The RFC mentions PHP 7.0 as proposed PHP version. Have you considered the PHP 7.0 timeline RFC[1]? As I understand it, any RFC put up to vote after 2015-03-15 cannot target PHP 7.0. Then again, if this will be considered a bug fix, an RFC would not be necessary at all (if I'm not mistaken). [1] https://wiki.php.net/rfc/php7timeline -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
De : Dan Ackroyd [mailto:dan...@basereality.com] On 19 March 2015 at 17:14, François Laupretre franc...@php.net wrote: As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. What. The. Fuck. You edited the RFC after the voting had closed? You are not allowed to edit an RFC after the voting has occurred. I don't think we have any rules in place to deal with this; I don't think anyone anticipated that anyone would actually try to do this. We obviously need an explicit rule for this, but that can wait until 7.0 is closer to shipping, and we can contemplate RFC rules at leisure. For now, please revert the changes your made to the RFC after it had been closed. And whoever has the power to remove karma, please take the power to edit RFCs away from Francois once that has been done. Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2. You are being dumb here as well. We try to avoid breaking code in point releases. This BC break can only be done at a major version. OK. OK. I revert the RFC to its original version. It will raise E_RECOVERABLE_ERROR in 7.0. Before you burn me alive, here's what happened : I was in Africa during the last 3 weeks, and didn't have any way to post to the list. I just had one hour of internet access during all this time and wanted to use it to close the vote, but I saw Zeev's and Julien's comments asking for a deprecate phase in 7.0, and thought that, if there was a rule, I had to respect it. I am not as dumb as you may think, I know BC breaks must be introduced in major versions, but the requests to do so were coming from people who are supposed to know the rules better than I. So, I added a line at the end of the RFC and sent a private message via twitter to Zeev asking him to forward the information to the list to discuss whether this change after vote was considered as acceptable or not. Unfortunately, I discovered his reply this morning saying he preferred me to do it when I would be back. That's why you discovered it today. So, I probably shouldn't have modified the RFC when I closed the vote, but there was a context. So, as it is not clear whether there's a rule saying that everything must be deprecated before being removed, I will implement the RFC exactly as it was voted. And let me apologize for the misunderstandings I have caused. Regards François I thought introducing a temporary E_DEPRECATED phase would be acceptable to everyone and I would have asked the list but I could not send emails from where I was during the last 2 weeks. I just had web access during 1 hour, read Zeev's and Julien's comments, added one line in the RFC, and then sent a twitter message to Zeev asking him to forward the change to the list so that it could be judged acceptable or not. Unfortunately, was in Africa during the last 2 weekssatisfy everyone but it seems it is not the case. Now, what should I say when people who are supposed to know the process better than me ask to delay the BC break to 7.1 or 7.2 ? cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?
On 03/19/2015 01:26 PM, Eric Stenson wrote: PHP Internals folks-- We're doing some performance work in WinCache, and we're finding that some frameworks are...uh...enthusiastically using file_exists(), is_file() and is_dir() functions on files/directories that don't exist. Every. Single. Pageload. Does the PHP stat cache include negative cache entries? If not, why not? Are there any existing extensions that implement a negative cache for file_exists(), is_file(), et. al.? We do not do negative caching. This is documented at http://php.net/manual/en/function.clearstatcache.php where it says: You should also note that PHP doesn't cache information about non-existent files. So, if you call file_exists() on a file that doesn't exist, it will return FALSE until you create the file. If you create the file, it will return TRUE even if you then delete the file. However unlink() clears the cache automatically. But, I think you are also missing the fact that the stat cache is per-request. So your every single pageload aspect won't be helped by adding negative caching to the stat cache. It is still going to stat on every single page load. It is only multiple identical stats within the same request that gets caught by the stat cache. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?
On Fri, Mar 20, 2015 at 12:09 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 03/19/2015 01:26 PM, Eric Stenson wrote: PHP Internals folks-- We're doing some performance work in WinCache, and we're finding that some frameworks are...uh...enthusiastically using file_exists(), is_file() and is_dir() functions on files/directories that don't exist. Every. Single. Pageload. Does the PHP stat cache include negative cache entries? If not, why not? Are there any existing extensions that implement a negative cache for file_exists(), is_file(), et. al.? We do not do negative caching. This is documented at http://php.net/manual/en/function.clearstatcache.php where it says: You should also note that PHP doesn't cache information about non-existent files. So, if you call file_exists() on a file that doesn't exist, it will return FALSE until you create the file. If you create the file, it will return TRUE even if you then delete the file. However unlink() clears the cache automatically. But, I think you are also missing the fact that the stat cache is per-request. So your every single pageload aspect won't be helped by adding negative caching to the stat cache. It is still going to stat on every single page load. It is only multiple identical stats within the same request that gets caught by the stat cache. Thanks :) I forgot to mention that here (but in a chat :). Also it would help a little bit as some apps repeatedly check files or paths in the same request. However I am not sure it is worth the addition. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
I'm not sure why it would duplicate the item like that. My interpretation of $array[$start:$end] would be an array containing all those elements of $array with a position more than or equal to $start, but less than or equal to $end ($position = $start $position = $end). I agree with this statement now, I was misinterpreting how I thought it should work, but reading this; I think you're right. Also, your next point about the unique array indexes covers it anyway, so it doesn't really matter regardless. Check my example again. $countdown[0] refers to the element with key 0, so is absolutely not a replacement for $countdown[0:0]. This is the whole point of my example. You're correct, this was my mistake. I'm not sure what you mean by something that happens nowhere else PHP has syntax for all sorts of things, using all sorts of symbols. Your own suggestion uses the : symbol in a place where it currently can't exist. What I mean by 'symbol' here, is a prefix to tell it what the context of its use is; in this case, it is the declaration that we are requiring the index not the key. As far as I'm aware, and can think of at the moment, PHP has nothing like a hinter symbol. The only purpose of this symbol is to tell the user that it is indexes not keys. Maybe there should be a symbol to declare that, but i'm not sure. Will appreciate more comments on this. If we go the direction of using a symbol, what should be the outcome of the symbol missing? fatal error, or to try to slice based on the keys?
RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
May I also add that it is not the first time people raise concerns about RFCs when vote starts. On different occasions, it was clear that most had not read the RFC before the vote was announced. I even have two RFCs which were planned for 7.0 and won't be in because I had to stop the vote and restart a discussion. When we have short timelines, as for 7.0, it's a real problem because restarting a discussion easily adds one month to the approval process. Actually, I don't know if, in this case, I shouldn't reply that the discussion is over and that it's just too late to wake up. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?
On 19 March 2015 at 20:26, Eric Stenson erics...@microsoft.com wrote: PHP Internals folks-- We're doing some performance work in WinCache, and we're finding that some frameworks are...uh...enthusiastically using file_exists(), is_file() and is_dir() functions on files/directories that don't exist. Every. Single. Pageload. What context are these filesystem hits in, is it class autoloading by any chance? If so there was a function added to OPCache and a hopefully upcoming feature to Composer that may be of interest. http://php.net/manual/en/function.opcache-is-script-cached.php https://github.com/composer/composer/pull/3802 Those two combined eliminate a huge number of file_exists calls, similar to what you are describing. Though I guess the is_file and is_dir functions might be in a different area of code. Does the PHP stat cache include negative cache entries? If not, why not? Negative caches tend to just be the wrong thing. A positive cache returns usable data, with the proviso that the data might be out of date. A negative cache, returns nothing usable. For example, a browser caching a page that returns a 200 response is fine, as it's caching some information that was acceptable. A browser caching a 50x error page would just be caching useless information. Another example - the Composer autoloader behaves as a negative cache, in that it caches the 'fact' that a class doesn't exist. This gets in the way of being able to dynamically generate code, as once you've called `class_exists(SomeAutogeneratedClass, true);` you can no longer use the registered autoloaders to load that class, and instead have to load it by hand. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Mar 20, 2015 12:14 AM, François Laupretre franc...@php.net wrote: De : Zeev Suraski [mailto:z...@zend.com] https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates from our guidelines of deprecating features first, and removing them later; It’s addressed in the RFC – but I’m a bit worried that this opens the door to jumping from any sort of notice/warning into errors or removed features without any deprecation phase. In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through E_DEPRECATED. Should we not go through this deprecation cycle, even if may feel anxious to get rid of this behavior? Sorry for the delay but I could not send emails during the last 3 weeks. As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2. Hmm.. Sorry but no. I really do not think we can do this, this will bring a major BC in 7.1+ and we do not allow BC but in extreme cases. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. Well, if it is, do it in 7.0. But changing that all of a sudden and making it fatal in 7.1+ is an extremely bad idea :) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On 19 March 2015 at 17:14, François Laupretre franc...@php.net wrote: As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. What. The. Fuck. You edited the RFC after the voting had closed? You are not allowed to edit an RFC after the voting has occurred. I don't think we have any rules in place to deal with this; I don't think anyone anticipated that anyone would actually try to do this. We obviously need an explicit rule for this, but that can wait until 7.0 is closer to shipping, and we can contemplate RFC rules at leisure. For now, please revert the changes your made to the RFC after it had been closed. And whoever has the power to remove karma, please take the power to edit RFCs away from Francois once that has been done. Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2. You are being dumb here as well. We try to avoid breaking code in point releases. This BC break can only be done at a major version. E_DEPRECATED is not a magic bullet - that makes all BC problems go away. The reason why we voted on it for 7.0 is that it is a major break, but one that is acceptable to be done at a major version. It would not be acceptable to change the behaviour in a minor version. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
There's then the question of what kind of object it would return - a Closure? Some child or sibling of Closure? What methods could be usefully provided? Yes, it's a closure. I've actually fleshed this out quite a bit, and there are a few important questions: - With methods do you allow unbound closures? `callable(Foo::method)` ? - How do you provide a context object? Two parameters? If so, what order? The object first makes more sense, but that means you have a string for your first parameter when there is only one, but an object if there are two. So you put the context second and it's kind of weird to do `callable(method, $foo)` Also note that if we had a unified table for properties, methods and constatns this is vastly simplified: - $foo::method could provide an unbound, scoped closure - $foo-method could provide a bound closure Or you do alternative grammar rules inside of callable, such that `callable(foo::method)` must would check for a method instead of a constant. All in all, I really wish we had unified properties, methods and constants. It would also have the advantage that if you have a property of an object that is a callable you could call it with normal syntax `$foo-property()` instead of having to do things like `$f = $foo-property; $f()`. Callable might work, though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On 19 במרץ 2015, at 19:40, Dan Ackroyd dan...@basereality.com wrote: You are being dumb here as well. We try to avoid breaking code in point releases. This BC break can only be done at a major version. Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase. So why I agree with you it's a problem to just edit the RFC without getting a wide OK for it after a vote has concluded, what's much worse is that so many people voted Yes for an RFC that violated that principle, and not s single person was bothered to even reply to a query about it. Note that contrary to what you said, a vote would have been equally required regardless of whether we follow our deprecation process, or violate it for no good reason. You're right we won't be able to move to remove it in 7.x - but it's exactly at the same level that we mustn't move to an error in 7.0. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Dan Ackroyd wrote on 19/03/2015 17:40: On 19 March 2015 at 17:14, François Laupretre franc...@php.net wrote: As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. What. The. Fuck. I agree with the substance of what you wrote, but would like to appeal for some civility and Assumption of Good Faith. When you find yourself typing the word fuck on a public mailing list, you should pause, make a cup of tea, and redraft the e-mail. You edited the RFC after the voting had closed? You are not allowed to edit an RFC after the voting has occurred. Yes, this was not a good idea. The RFC as accepted was for a fatal error; a change to E_DEPRECATED would require a new RFC, or at least a supplementary vote. I don't think we have any rules in place to deal with this; I don't think anyone anticipated that anyone would actually try to do this. We obviously need an explicit rule for this, but that can wait until 7.0 is closer to shipping, and we can contemplate RFC rules at leisure. For now, please revert the changes your made to the RFC after it had been closed. And whoever has the power to remove karma, please take the power to edit RFCs away from Francois once that has been done. Let's keep this in perspective - no permanent harm has been done, anyone can revert the page, and Francois can learn from the mistake. These two paragraphs can be boiled down to Can you or someone revert it please, to reflect the text as accepted. Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2. You are being dumb here as well. This sentence is simply unnecessary. We try to avoid breaking code in point releases. This BC break can only be done at a major version. E_DEPRECATED is not a magic bullet - that makes all BC problems go away. The reason why we voted on it for 7.0 is that it is a major break, but one that is acceptable to be done at a major version. It would not be acceptable to change the behaviour in a minor version. This point is valid. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Thu, Mar 19, 2015 at 1:40 PM, Dan Ackroyd dan...@basereality.com wrote: On 19 March 2015 at 17:14, François Laupretre franc...@php.net wrote: As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. You edited the RFC after the voting had closed? You are not allowed to edit an RFC after the voting has occurred. Agreed. I hereby change my vote from 'Yes' to 'No' in protest of this action. For now, please revert the changes your made to the RFC after it had been closed. Please. If we need to change the schedule, let that be a separate RFC. And whoever has the power to remove karma, please take the power to edit RFCs away from Francois once that has been done. Now that's a bit heavy-handed. Let's call this a slap on the wrist and move on. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi,
Am 19.03.2015 um 20:26 schrieb Levi Morrison:
On Thu, Mar 19, 2015 at 1:05 PM, Dennis Birkholz den...@birkholz.biz wrote:
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
but before that happens, we should make closures serializable.
What does closures being serializable have to do with this feature?
If you replace the array($object, 'method') syntax by callable($object,
'method') which returns a closure, you can not serialize callables any
more which is currently possible. Before we replace working language
features by closures we should update closures to be usable in all
required situations.
Greets
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
De : Zeev Suraski [mailto:z...@zend.com] https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates from our guidelines of deprecating features first, and removing them later; It’s addressed in the RFC – but I’m a bit worried that this opens the door to jumping from any sort of notice/warning into errors or removed features without any deprecation phase. In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through E_DEPRECATED. Should we not go through this deprecation cycle, even if may feel anxious to get rid of this behavior? Sorry for the delay but I could not send emails during the last 3 weeks. As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Thu, Mar 19, 2015 at 11:49 AM, Zeev Suraski z...@zend.com wrote: On 19 במרץ 2015, at 19:40, Dan Ackroyd dan...@basereality.com wrote: You are being dumb here as well. We try to avoid breaking code in point releases. This BC break can only be done at a major version. Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase. We have historically broke BC a lot without deprecation. I also know of no such rule in our written RFCs. If historical behavior says otherwise, and we don't have this written down anywhere... how can you claim this is a rule? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
Levi Morrison wrote: Whatever you want to improve, please consider that the PHP wiki is driven by DokuWiki which needs to get updated from time to time (lately there have been two updates every year[1]; this is not accounting any necessary updates to DokuWiki plugins). These updates seem to be painful already, due to the required customizations. It would be helpful if further as well as existing customizations could be moved to custom DokuWiki plugins as far as feasible. Thankfully I've never had to do that part myself. Do we have a document somewhere that explains our general update/upgrade procedure for DokuWiki? Maybe now that PHP 7.0 is in feature freeze I can find some time to work on our web infrastructure again. To my knowledge there is no such document; at least there's nothing in the web-wiki repo[1]. However, upgrading DokuWiki installations is usually rather painless.[2] The main issues would be code modifications and evetual changes to the DokuWiki API. Anyhow, further discussion on this topic might better be done on webmaster@; perhaps my mail Maintenability of the Wiki implementation[3] is a good starting point. [1] http://git.php.net/?p=web/wiki.git;a=tree [2] https://www.dokuwiki.org/install:upgrade [3] http://news.php.net/php.webmaster/20899 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Thu, Mar 19, 2015 at 6:49 PM, Zeev Suraski z...@zend.com wrote: On 19 במרץ 2015, at 19:40, Dan Ackroyd dan...@basereality.com wrote: You are being dumb here as well. We try to avoid breaking code in point releases. This BC break can only be done at a major version. Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase. I don't think this is true. There is no requirement for us to deprecate something before we remove it. Deprecation is a courtesy to our users in cases where a heavily used feature is being dropped. Realistically most people consider E_NOTICE to be a higher error level than E_DEPRECATED. If somebody is willing to suppress the notices this currently generates, chances are very high that deprecations are suppressed as well. I don't see any release process issues with dropping this without deprecation. (But I'm still -1 on the change, because I don't see why we'd suddenly want to change this one relatively unimportant notice to be fatal while leaving everything else alone.) Nikita
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Sebastian B.-Hagensen wrote on 19/03/2015 16:27:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
Andrea proposed a slightly different syntax for function references a
few months back - see withdrawn RFC [1] and accompanying Internals
thread [2].
I actually quite like the callable() syntax. Whereas Andrea's suggestion
was a parser rule that took a bare string, like foo, this would have to
always take a string, like callable('foo'), but that's good if we want
to roll in dynamic callbacks as well:
Right now, we have to embed the type information in the variable name,
because this is just a string:
$hook_callback = 'hook_' . $hook_name;
This has a much strong information scent:
$hook = callable('hook_' . $hook_name);
There's then the question of what kind of object it would return - a
Closure? Some child or sibling of Closure? What methods could be
usefully provided?
What should happen if the arguments provided aren't callable? Throw an
exception?
Also, do we still need a way to delay testing of callability, to allow this:
class A {
private function foo() { echo 'foo'; }
public function bar(callable $call) { $call(); }
}
$a = new A;
// A::foo is not callable here, but will be when we get inside A::bar
var_dump(is_callable([$a, 'foo'] ));
$a-bar( [$a, 'foo'] );
Currently works: http://3v4l.org/pNZgn
[1] https://wiki.php.net/rfc/function_referencing
[2] http://marc.info/?t=14071027541r=2w=2
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Hi Zeev, On 19 March 2015 at 17:49, Zeev Suraski z...@zend.com wrote: Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase. Please can you point me to where this is written down? Please also show me where it says that this rule cannot be over-ridden by an RFC, which is our path of changing rules. The point of deprecating things is to smooth the path of fixing issues. It allows people to detect in their codebase places where there is code that is currently working fine without error, that is going to break in a future version of PHP. Any array to string conversion is already detectable as it emits a 'notice'. It does not need an intermediate step of changing the notice to being a deprecation warning; that provides no benefit to users. Rowan wrote: you should pause, make a cup of tea, and redraft the e-mail. That was the redrafted version. The edits to the RFC were made two weeks ago. In Francois' defence he himself alerted the list to the changes. But the unapproved editing also meant that if there was someone else who was concerned about the BC break, they might not have raised an RFC to revert the RFC, before the cut off time for RFCs. This is one of the reasons why someone editing the text of a passed RFC is utterly unacceptable. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] WIKI Account Request
Hello Internals, I had requested a wiki account (mwillbanks) as I would like to propose an RFC on Object casts to scalar types. This has previously been discussed prior to scalar type hints and since we have those now coming into PHP 7, I believe it would be a great time to take a look at this for 7.1 (Discussion will not be immediate as focus needs to be put into 7.0) The last RFC had gone inactive back from 2012: https://wiki.php.net/rfc/object_cast_to_types and I have talked with ircmaxell about doing something similar but making it more inline with STH as well as supporting a generalized __cast. The general cruft of it is to have objects have the ability to support: + __toInt + __toFloat + __toBool + __toArray + __cast Removing the existing having __toScalar as it would no longer make sense in this context. __cast would be utilized more or less as function((int) constant_type) where as it may mean PHP_TYPE_* as initial feedback on the idea showed that it would be the most generalist approach and might be useful in that context. Regards, Mike
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
but before that happens, we should make closures serializable.
Greets
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Hi! As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. What. The. Fuck. Let's tone down here. While editing RFC anytime after the vote has started without advanced notice is unacceptable and should not be done, I don't think it's anything but a honest mistake. Of course, even more unacceptable is to change it when voting results are in. But let's not create more drama of it then necessary. Wikipedia has a rule that says assume good faith (yes, I know in practice it is more complicated :) - I think we could use more invocation of this rule here too. It looks like the RFC author has not really decided what he wants to do. If he doesn't want to support the RFC anymore, as voted, he can just withdraw it and let somebody pick it up if willing (that's what happened to = RFC and scalar typing RFC, so we have precedents). Or create a new different one to supersede the old one. What not should be done of course is editing voted RFC and using that as a base for changes. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
On Thu, Mar 19, 2015 at 1:05 PM, Dennis Birkholz den...@birkholz.biz wrote:
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
but before that happens, we should make closures serializable.
What does closures being serializable have to do with this feature?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
On Thu, Mar 19, 2015 at 1:44 PM, Dennis Birkholz den...@birkholz.biz wrote:
Hi,
Am 19.03.2015 um 20:26 schrieb Levi Morrison:
On Thu, Mar 19, 2015 at 1:05 PM, Dennis Birkholz den...@birkholz.biz wrote:
Hi,
Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
but before that happens, we should make closures serializable.
What does closures being serializable have to do with this feature?
If you replace the array($object, 'method') syntax by callable($object,
'method') which returns a closure, you can not serialize callables any
more which is currently possible. Before we replace working language
features by closures we should update closures to be usable in all
required situations.
Many callable are inherently not serializable. This is not solvable in
the general case.
Why are you serializing array($object, method) callable currently?
(As in, what is the use case?)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 3/19/15 4:06 PM, Alex Bowers wrote: I've had a quick scan of the list at https://wiki.php.net/rfc but cannot seem to find anything. I'll read more carefully through, or is there a different list elsewhere which I should look at? Not everything makes it to an RFC. This list's archives are quite extensive. (People here are verbose): http://php.net/mailing-lists.php http://marc.info/?l=php-internals Also, no top-posting, please. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 19 March 2015 at 21:11, Larry Garfield la...@garfieldtech.com wrote: On 3/19/15 4:06 PM, Alex Bowers wrote: I've had a quick scan of the list at https://wiki.php.net/rfc but cannot seem to find anything. I'll read more carefully through, or is there a different list elsewhere which I should look at? Not everything makes it to an RFC. This list's archives are quite extensive. (People here are verbose): http://php.net/mailing-lists.php http://marc.info/?l=php-internals Also, no top-posting, please. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Apologies about the top post, that was gmail automatically hiding the main content so I just typed. Thanks for the links. I will look through them now to find some proposals which have failed before; and try to improve this one. Still would like feedback from anybody else reading this too. Thanks.
[PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?
PHP Internals folks-- We're doing some performance work in WinCache, and we're finding that some frameworks are...uh...enthusiastically using file_exists(), is_file() and is_dir() functions on files/directories that don't exist. Every. Single. Pageload. Does the PHP stat cache include negative cache entries? If not, why not? Are there any existing extensions that implement a negative cache for file_exists(), is_file(), et. al.? Thank you! --E. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC - Array slice syntactic sugar
This email is just to gauge the response for some syntactic sugar to be added to PHP in regard to slicing an array. My proposal is something similar to Pythons slice, in PHP this would look like: $slided = $array[1:4] This will get the elements in positions 1,2,3,4. (1 through 4 inclusive), ignoring the actual key of the array. The result for an array will be an array with the keys preserved, in the same order. Any multi-dimensions are also respected and returned within the array. This is the same as using the array_slice method with the PRESERVE KEYS fourth parameter passed through as true. The result for a string is the string from the two positions indicated. This is the same as using substr(). The benefits for this as I see it is: 1) No function overhead 2) More readable (opinionated) 3) Consistent with how we can select items from an array currently (using index). If the array is not long enough (for example, index 4 doesn't exist), then a NOTICE is thrown, and the values returned are as much as possible; this would be the same as calling $array[1:] which will get the items in position 1 through to the end. If the variable used contains a string, then this will get the values from the string at those positions. The same way that $string[1] will get the second character, $string[2:5] will get the third through to the sixth character. This differs from array_slice which would throw a warning and return null. If the variable isn't either a string or an array (or convertible to either); then a warning is thrown and null is returned, consistent with current use ($int[0] will return null) Arrays with associated keys cannot be selected by using the keys they have, but instead should be selected by the position those keys hold. For example, this is invalid: $array['string':'end']. This should throw a fatal error. The valid options are: $array[from:to] - This gets the values from position 'from' to 'to' inclusive $array[from:] - This gets the values from the position 'from' to the end. $array[:to] - This gets the values from the start to the position 'to'. $array[:] will get all the items in the array ($same as doing $array) A side addition, that may be considered is adding [-1] to get the last item in the array. But that is not a main part of this RFC. Thanks
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 3/19/15 3:49 PM, Alex Bowers wrote: This email is just to gauge the response for some syntactic sugar to be added to PHP in regard to slicing an array. My proposal is something similar to Pythons slice, in PHP this would look like: $slided = $array[1:4] This will get the elements in positions 1,2,3,4. (1 through 4 inclusive), ignoring the actual key of the array. The result for an array will be an array with the keys preserved, in the same order. Any multi-dimensions are also respected and returned within the array. This is the same as using the array_slice method with the PRESERVE KEYS fourth parameter passed through as true. The result for a string is the string from the two positions indicated. This is the same as using substr(). The benefits for this as I see it is: 1) No function overhead 2) More readable (opinionated) 3) Consistent with how we can select items from an array currently (using index). If the array is not long enough (for example, index 4 doesn't exist), then a NOTICE is thrown, and the values returned are as much as possible; this would be the same as calling $array[1:] which will get the items in position 1 through to the end. If the variable used contains a string, then this will get the values from the string at those positions. The same way that $string[1] will get the second character, $string[2:5] will get the third through to the sixth character. This differs from array_slice which would throw a warning and return null. If the variable isn't either a string or an array (or convertible to either); then a warning is thrown and null is returned, consistent with current use ($int[0] will return null) Arrays with associated keys cannot be selected by using the keys they have, but instead should be selected by the position those keys hold. For example, this is invalid: $array['string':'end']. This should throw a fatal error. The valid options are: $array[from:to] - This gets the values from position 'from' to 'to' inclusive $array[from:] - This gets the values from the position 'from' to the end. $array[:to] - This gets the values from the start to the position 'to'. $array[:] will get all the items in the array ($same as doing $array) A side addition, that may be considered is adding [-1] to get the last item in the array. But that is not a main part of this RFC. Thanks Variations of this proposal have been discussed many times. I don't recall what the pushback was but it's worth your time to check the archives to see what the objections were and if you can address them, and/or if the new engine in PHP 7 addresses them. (I suspect it has/will ameliorate a lot of implementation-level issues with old proposals.) Personally I'd be in favor of such a syntax but I don't recall the objections in the past beyond meh, sugar. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
I've had a quick scan of the list at https://wiki.php.net/rfc but cannot seem to find anything. I'll read more carefully through, or is there a different list elsewhere which I should look at? On 19 March 2015 at 21:03, Larry Garfield la...@garfieldtech.com wrote: On 3/19/15 3:49 PM, Alex Bowers wrote: This email is just to gauge the response for some syntactic sugar to be added to PHP in regard to slicing an array. My proposal is something similar to Pythons slice, in PHP this would look like: $slided = $array[1:4] This will get the elements in positions 1,2,3,4. (1 through 4 inclusive), ignoring the actual key of the array. The result for an array will be an array with the keys preserved, in the same order. Any multi-dimensions are also respected and returned within the array. This is the same as using the array_slice method with the PRESERVE KEYS fourth parameter passed through as true. The result for a string is the string from the two positions indicated. This is the same as using substr(). The benefits for this as I see it is: 1) No function overhead 2) More readable (opinionated) 3) Consistent with how we can select items from an array currently (using index). If the array is not long enough (for example, index 4 doesn't exist), then a NOTICE is thrown, and the values returned are as much as possible; this would be the same as calling $array[1:] which will get the items in position 1 through to the end. If the variable used contains a string, then this will get the values from the string at those positions. The same way that $string[1] will get the second character, $string[2:5] will get the third through to the sixth character. This differs from array_slice which would throw a warning and return null. If the variable isn't either a string or an array (or convertible to either); then a warning is thrown and null is returned, consistent with current use ($int[0] will return null) Arrays with associated keys cannot be selected by using the keys they have, but instead should be selected by the position those keys hold. For example, this is invalid: $array['string':'end']. This should throw a fatal error. The valid options are: $array[from:to] - This gets the values from position 'from' to 'to' inclusive $array[from:] - This gets the values from the position 'from' to the end. $array[:to] - This gets the values from the start to the position 'to'. $array[:] will get all the items in the array ($same as doing $array) A side addition, that may be considered is adding [-1] to get the last item in the array. But that is not a main part of this RFC. Thanks Variations of this proposal have been discussed many times. I don't recall what the pushback was but it's worth your time to check the archives to see what the objections were and if you can address them, and/or if the new engine in PHP 7 addresses them. (I suspect it has/will ameliorate a lot of implementation-level issues with old proposals.) Personally I'd be in favor of such a syntax but I don't recall the objections in the past beyond meh, sugar. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi Sebastian,
On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com wrote:
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would you write an callback containing an already constructed
object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
I'm not proposing deprecate it soon, but in the long run.
It will need a decade to deprecate it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Then how would you write an callback containing an already constructed object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
$object-$methodName(...$args);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
On Thursday 19 March 2015 18:17:50 S.A.N wrote:
Then how would you write an callback containing an already constructed
object? $a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
$object-$methodName(...$args);
That's a call. Requested was an assignment. You cannot assign that and pass it
around for later calling. You cannot pass that as a callable parameter.
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi,
2015-03-19 17:17 GMT+01:00 S.A.N ua.san.a...@gmail.com:
Then how would you write an callback containing an already constructed
object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
$object-$methodName(...$args);
You would still need an array to pass the information about the
callback to another context. The syntax you detailed is not usable by
the callable typehint and internal functions requiring a callback. No
improvement made. The better alternative may be to deprecate strings
as callbacks (if one should be deprecated at all) and always require a
closure or or an array with one of the following signatures
array(string); array(string, string); array(object, string)
Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
I've always liked how callbacks (well, function pointers) are handled in C -
using the function name without parentheses. eg.
$a = $object-method;
But this wouldn't work in PHP as is, since property and method names would
collide. How do people feel about the fact that we have separate property and
method namespaces? Does it add value?
Vik
On Thursday, 19 March 2015, 12:48, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com wrote:
Hi,
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would you write an callback containing an already constructed object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
