[PHP-DEV] FD_SETSIZE warning?
I'm flooded with this warning when my system is under a high load and uses a lot of sockets/file descriptors. I get it in stream_select: E_WARNING: E_WARNING caught: stream_select(): You MUST recompile PHP with a larger value of FD_SETSIZE. It is set to 1024, but you have descriptors numbered at least as high as 1024. --enable-fd-setsize=2048 is recommended, but you may want to set it to equal the maximum number of open files supported by your system, in order to avoid seeing this error again at a later date. Why would you even have a limit for this? Having your application suddenly crash because of some undocumented arbitrary internal PHP limit is a real punch-in-the-face for people trying to build robust PHP-CGI applications. Can someone explain to me why I need to be bothered about this? ~Hannes
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
Hi, I'd +1 moving to git. I just moved my own project to github from our own SVN. Mainly for economical reasons as this allowed us to not have to maintain our own repository and because github had excellent features. Another point was of course git's superiority over svn when it comes to many basic features such as keeping your own local repository, branching, tagging etc. I'd also recommend that you see this insightful and hilarious talk by Linus Torvalds if you haven't already: http://www.youtube.com/watch?v=4XpnKHJAok8 ~Hannes
Re: [PHP-DEV] [VOTE] Weak References
Good explanation Ferenc. Yeah I think there's a lot of misunderstandings going on with weak/soft references and how the garbage collector works. Weak/soft references is not some kind of solution to the cyclic reference problem. The GC takes care of that already. You can use whatever OOP patterns with whatever reference graphs you like Lars, the GC will free the entire structure as soon as the cyclic collector runs after you are not referencing it anymore. You might have become a bit confused with my last post where I explained how one could theoretically hack together a soft reference implementation by using weak references and some properties of cyclic collection. Also property access performance is off-topic. - Weak references solves the loose coupled object indexing problem. I need this reference as long as it's referenced somewhere else. - Soft references solves the caching problem. I need this reference as long as we have plenty of memory available. - The GC solves the cyclic reference problem (since 5.3). ~Hannes
Re: [PHP-DEV] [VOTE] Weak References
Hello, We had a healthy discussion around WR and I have been able to express my concerns. The consensus is clearly to put it in a PECL extension so I think this discussion should move on to the practical matters of doing this. I suggest aborting the vote and changing the RFC state to something like Transfered to PECL. ~Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Good idea. I will see what I can do when I get time. ~Hannes On 3 August 2011 12:32, Pierre Joye pierre@gmail.com wrote: hi Hannes, I would suggest to still update the RFC with the various very instructive comments and example use cases you use in this thread. Doing the same in the long run should help as well to understand the goals, implementations, etc., for the pecl users or for the 2nd attempt to get it in the core, if still desired. Cheers, On Wed, Aug 3, 2011 at 12:25 PM, Hannes Landeholm landeh...@gmail.com wrote: Hello, We had a healthy discussion around WR and I have been able to express my concerns. The consensus is clearly to put it in a PECL extension so I think this discussion should move on to the practical matters of doing this. I suggest aborting the vote and changing the RFC state to something like Transfered to PECL. ~Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
I've talked to Etienne and he still believes we should vote on this so the vote is still up. He just replied to quickly. If the vote fails the patch can still be implemented in a PECL extension. There's no point canceling the vote or the RFC - it's still valid and ongoing, and there is still time for discussion. The problem is that PECL is not an option for all users. If you're using shared hosting and otherwise don't have control over what extensions is loaded or not then essentially you'll be unable to use a framework that takes advantage of weak references. That's the reality of many freelancing developers and small-scale sites out there. It's especially problematic for framework designers that builds ORM-layers - they can't tell their users oh btw you need to install this non standard PECL extension for it to work. Or rather, you can but then the user will be angry. I don't think because they can is a good argument for why features should generally be outsourced as PECL extensions. Complex, experimental stuff that solves specific integration or performance problems is great for PECL. But generic object orientation design fundamentals should be implemented in the core since people rather have their framework leak a bit more memory (and risk running out of it in edge cases) or design their application more clumsy than depend on a non-standard PECL extension. It's about allowing people to do elegant design. A good developer would choose compatibility over elegant design any day - so if the language wants people to do design great applications the language needs to provide those tools natively. I realize I need to provide some kind of realistic scenario for you to understand so let's put ourselves in the shoes of Joe Codeguy - he's currently designing the an application that will edit inventory details at a small company with 10 employees. It is hosted at a shared hosting provider since they are running a tight budget. They can't afford their own servers or an IT guy. The employers regularly login to the application and updates the inventory. Joe Codeguy has designed the application so that there are one Product class that is loaded from the database where each products table row corresponds to a product. Certain function in the application runs a MySQL procedure that updates a certain complex selection of products in the products database rendering the currently loaded products in memory obsolete since they might have been updated. After this procedure runs all Product class objects in memory will need to be reloaded. Joe Codeguy fixes this by implementing the observer pattern (PEAR Event_Dispatcher) so that whenever a Product is loaded or created it registers itself on a global event called EVENT_PRODUCT_RELOAD. He then proceeds to trigger the event whenever the complex MySQL procedure updates the database table. Everything seems to be working fine so he deploys the application. One days later the customer complains that a certain critical operation no longer works. Joe then find a subroutine while debugging that loops trough a quite large selection of thousands of products one by one and makes some complicated calculations. During this loop the application faces a out of memory condition. Joe thinks this is strange because it only operates on one product at a time. He then realizes that the observer registration prevents the products from being garbage collected properly since they are strongly referenced by Event_Dispatcher. Thankfully PHP implements weak references so he can correct Event_Dispatcher to use weak referencing instead. However it's outsourced into a PECL extension and since Joe cannot install extensions into the production server he is forced to use unset hacks in the faulty loops to correct the issue. Joe deploys the application again and can only hope that this was the only loop that triggered the memory problem and that the application doesn't crash anywhere else when the products table grows larger. Also even if an application doesn't run out of memory there might be a serious performance impact from the memory leaked by objects that can't be collected properly. If an application peaks at 15 MB instead of 25 MB, the server can run 40% more child threads in parallel. Regards, ~Hannes On 2 August 2011 17:16, Lester Caine les...@lsces.co.uk wrote: The fast development root does seem to have been a little screwed up recently, but if there is nothing in an extension that requires direct access to the core and that extension CAN simply be enabled as required, then pecl is the way to go? We do need the pecl area to be properly included in the build process with windows builds being created just as they used to be, but the process is working fine for APC and perhaps the plan should be to moving some more extensions that are being worked on between PHP releases into the pecl process? It used to be that many of the extensions I used were managed in pecl ... and I'd be quite
Re: [PHP-DEV] [VOTE] Weak References
On 2 August 2011 23:32, Chris Stockton chrisstockto...@gmail.com wrote: I would like to make a couple points here, first I is that PECL is not a place for a extension to rot, that statement makes absolutely no sense to me. PDO I recall years ago getting from PECL, Http a extension I often use, was recently on this list if I recall to be moved into the core. I'm sure there are plenty of people on this list that were part of extension's PECL - CORE lifecycles that could add several more examples to the list. I believe PECL Would be a great place for something like this that was is entirely understood or has overwhelming support in my opinion. I don't agree with the concept of putting new feature in PECL itself. I would happily agree with putting it there if actually believed that it was there it belonged. Theoretically speaking weak references _is_ a core feature since it touches on garbage collection. If you followed the discussion the last weeks you'll see that the patch was intentionally weakened in functionality so no changes would have to be made to the GC (The catch collection event feature was removed/not implemented.). The reason behind this was so that it would not require much testing and have a larger chance of being merged into 5.4. This had the side effect of making it technically implementable as a PECL extension which was never intended. Rather I feel like this is instead used as an opportunity to delay it because it is difficult to put yourself in the situation of the marginal number of PHP developers that needs it. Yes, I admit that the number of people that care about the feature and knows what weak references are can be described as marginal but I also believe all frustrations are worth taking a shot at - especially the frustrations of the more advanced developer segment of the community. If they are not given the tools they need to implement the great design they envision they will look for other tools=languages instead and move on. The more great programmers that wants to use PHP the better position PHP has as a language and community. Also I think WR will have a huge impact when frameworks, event handlers, observer abstractions etc implements weak references and reduces the memory usage on a lot of applications out there. I am really not sure how comfortable I am with a feature as new as this being in the PHP on my servers. Some form of incubation, testing and use feedback only makes sense to me. If you don't use weak references there's no risk that anything breaks. The alpha and RC stage is exactly what incubation, testing and feedback is for. Second I would like to talk a little bit about weak references for those who are not familiar with them or have thus far only read your very strong pro-opinion. I would like to make it very clear with the simple fact that weak references are not required, ever by any language. They are a convenience, not a solution to a unsolvable problem. I believe that if anything weak references encourage laziness in design, it causes the referential integrity that I am accustomed to is broken, and can often lead to more code and checks then it relieves. No. Weak References _is_ a solution to an unsolvable problem. The problem is a subset of decoupling or separation of concerns theory in OOP. An example of the problem can be stated like this: - You need to design a framework in PHP. The framework should be decoupled from the application that uses it. This means that the data the application requests is undefined from the frameworks perspective. It should contain an ORM layer that maps exactly one object instance to a certain table row. If the frameworks fails to do this the application will have parallel instances of the same object row which is a corrupt data state. The application requests object instances by ID selection. The application may request a large number of object instances but never references more than what can be kept in memory at the same time. Design the ORM layer so that the application never faces an OOM condition. You may have the opinion that object oriented design problems aren't real problems. Fundamentally, design patterns does not solve any pure mathematical problems. Design patterns does not allow you to sort faster than O(n log n). Rather they solve an economical problem. By giving programmers the tools they need to write elegant code, the code becomes easier to understand, test and maintain. It saves the developer's time and the company's money. And most importantly, it makes programming fun. ;) It is very easy to run into unexpected bugs and in a language like PHP, where you don't get a NPE when you try to access a NULL method of a non object, you get a fatal error, this doesn't seem very appealing to me. Only under very specific cases of caching patterns as you have previously mentioned is such a pattern even recognized to -have a place for use that isn't just plain wrong- -not a
Re: [PHP-DEV] [VOTE] Weak References
Hello Stas, On 3 August 2011 02:39, Stas Malyshev smalys...@sugarcrm.com wrote: I notice some tone of hostility here. I'm not hostile. Perhaps a bit disappointed that the PECL objection wasn't brought up earlier in the discussion period so It could have been toughly discussed. /* snip */ This is why we tend to recommend to try the code outside the core if possible before taking it in. Yes, this is self evident. You seem to regard PECL as some kind of place where code goes to die. This is not so. Of course, some PECL extensions do wither and die of neglect, but others work just fine and have large user base - such as memcache support, apc, etc. Recommendation of PECL is not a punishment or disregard for your ideas or code - it is a recognition of the fact that not every new idea should immediately be implemented in the core. See the first paragraph in my previous post. If you think all proposals are more complex than this, you are obviously wrong. Most of recently added things into 5.4 in fact are conceptually simpler. Weak Reference: An object reference that does not prevent GC. I can't imagine something more conceptually simple although the use cases are not very simple. I don't think it's obvious why I am obviously wrong. Rapid release cycle doesn't mean that we immediately put into the release everything that was proposed up to the last second when it's supposed to be released. I'm referring to the fact that PHP has a major update once a year. Looking at it from an agile perspective this is insanely slow. I think you should use smaller iterations and release faster. The new Mozilla release schedule is a good example. If you need a solution for your use cases, I don't see how PECL extension wouldn't be fine. I have no problem compiling extensions and I also don't have any customers on share hosting. Although it wastes a bit more of my time I'm personally fine with PECL. I'm contributing to open source though so I'm concerned with the users that won't be able to run my code because they can't install PECL extensions. I'm also worried that it will takes years for WR to be moved to the core and that nobody will notice or use it. PHP deserves weak references. Not in a year but today. ~Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Tired... I don't agree with the concept of putting new feature in PECL itself... should of course be: I don't disagree with the concept of putting new feature in PECL itself... ~Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Weak References
Arguably the feature is already popular. I have pointed this out many times before but many other major OO languages provides weak references natively. Read the introduction in the RFC. Pragmatically speaking (as a framework designer) you are unfortunately not so privileged on what PECL/PHP extensions people should use and have loaded or not. Many hosting providers does not give you the option to load your own extensions and does not change the default configuration. So you are really avoiding non standard features when designing generic applications/frameworks that should be usable by anyone. This means that the PECL extension popularity proves nothing. Implementing it as a PECL extension will most likely prevent people from using it. I wouldn't. Finally to fully support Weak References in the future it has too make some small adjustments to the GC so the collection event can actually be caught (see rfc/additional cleanup and __destruct()). That might also be reason to why it should be implemented directly. Etienne Kneuss should be able to answer this better. ~Hannes On 1 August 2011 04:28, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I think I'm missing some important point here. Why this can't be implemented as PECL extension? I looked at the patch and saw nothing that requires engine involvement. So why not just create a PECL extension? If people start using it and it gets popular, we can merge it to core as we did with many others. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
[PHP-DEV] [VOTE] Weak References
Hello, Voting is now open for the weak references RFC. The RFC and patch can be found here: https://wiki.php.net/rfc/weakreferences You can vote here: https://wiki.php.net/rfc/weakreferences/vote I don't seem to be able to vote myself and I'm not sure if that's an error or not. Regards, Hannes Landeholm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Sorry that this was unclear, $obj is defined in the comment that says // compute $obj Imagine a SQL query there or otherwise code that constructs $obj from an external data source. Regards, Hannes On 1 August 2011 20:27, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, I like this idea. But I'd like to ask something; maybe someone could please correct the Example section of RFC? Unfortunately, I cannot understand how it could work on else conditional block, because $obj is undefined. Cheers, On Mon, Aug 1, 2011 at 1:46 PM, Hannes Landeholm landeh...@gmail.com wrote: Hello, Voting is now open for the weak references RFC. The RFC and patch can be found here: https://wiki.php.net/rfc/weakreferences You can vote here: https://wiki.php.net/rfc/weakreferences/vote I don't seem to be able to vote myself and I'm not sure if that's an error or not. Regards, Hannes Landeholm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Hello, I would just like to remind you that the voting will take place for 7 more days so there are still time to discuss your concerns. If you find something confusing or have objections I would be very interested in hearing them and discussing that _before_ you vote as I have reminded you twice now during the 2 week discussion period. Remember that people want this feature, so the least you can do is explain your objections before you vote no. Silently burying feature requests does not help anybody. aharvey: I'm surprised you voted no since you seemed content with the answers you got earlier. Do you have some special objection in mind? Cheers, ~Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
implementation and the limitations that has come with the language for the simplicity. Unfortunately I don't have time to wait for years even if many of you guys do. If I did I wouldn't have bothered writing the RFC or writing in this mailing list. You guys should look into this new rapid release cycle thing. It's the next iteration of software development. ~Hannes On 1 August 2011 21:16, Pierre Joye pierre@gmail.com wrote: hi, You have to start a new thread to begin a vote, see the voting RFC. So everyone will see it. However, I feel like it is premature to vote on that one. For one, I'm not convinced by this feature yet. I'm not sure it is the right way to do it, or if it is actually needed. The more I look at it the more I would recommend you to go with a pecl package, get feedbacks from the actual users (frameworkco) and come back once you have reached more maturity with both the design and the implementation of this feature. Don't be afraid to miss 5.4 either, next one comes next year :) Cheers, On Mon, Aug 1, 2011 at 6:46 PM, Hannes Landeholm landeh...@gmail.com wrote: Hello, Voting is now open for the weak references RFC. The RFC and patch can be found here: https://wiki.php.net/rfc/weakreferences You can vote here: https://wiki.php.net/rfc/weakreferences/vote I don't seem to be able to vote myself and I'm not sure if that's an error or not. Regards, Hannes Landeholm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Weak References
Hello, Voting is now open for the weak references RFC. The RFC and patch can be found here: https://wiki.php.net/rfc/weakreferences You can vote here: https://wiki.php.net/rfc/weakreferences/vote (This announcement was sent twice since the last announcement was merged with the existing thread instead of starting a new thread.) Regards, Hannes Landeholm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Weak References
Hi, I'd like to initiate voting on this RFC today since the minimum period of two weeks has now passed. Can someone with the right wiki powers/responsibilities start a vote and announce the [VOTE] on the mailing list? Thank you, ~Hannes
Re: [PHP-DEV] [RFC] Weak References
Hello guys, I'd just like to remind you that I plan to initiate voting for this RFC on Monday (less than 2 days) so if you plan on voting no, please reply here asap so we can discuss your concerns. Thank you for your time, ~Hannes
Re: [PHP-DEV] weak references
Lars: Please don't break up my sentences and take them out of context before you reply to them. (Hint: If a sentence begins with so it's not a good idea to just reply to that sentence.) If you are caching stuff you would rather want to use a strong reference since the objects should be retained between usages _per definition_. You might exploit weak references + destructor resurrection to achieve some kind of on-demand, unorthodox caching mechanism but that would not be a primary use cache for weak references, nor what you suggested (deallocate objects when OOM is reached). I have also given an example of how weak references is not necessarily used for caching, therefore not directly related to it. If you want to continue to discuss on demand deallocation, I suggest that you start a separate thread. I hope this will be more clear once the RFC is complete. I will then start a separate thread for official discussion. ~Hannes
[PHP-DEV] [RFC] Weak References
Hello, This is the official RFC discussion thread for Weak References and an announcement of the RFC. Please read the RFC before replying: https://wiki.php.net/rfc/weakreferences In a nutshell: The RFC proposes adding a single class called SplWeakRef which provides the Weak Reference feature. This is the only change. Previous thread was here: http://news.php.net/php.internals/53963 I'm creating this new thread for several reasons. First of all I feel that the RFC is now somewhat complete and an announcement should be formally made with the [RFC] subject in accordance to the voting procedure. Also the other thread has more general discussion on internal reference counting and garbage collection. Please keep this thread on topic - specifically about Weak References and the RFC. If you plan on voting no to this feature, please reply to this thread so we can discuss your concerns. As I've previously stated, I hope that this feature can be released with PHP 5.4 since I need it for my own projects and open source framework. I don't think this is unreasonable since it's such a simple class and also non-controversial. It has been an established feature in many other major OOP languages for years. I will therefore initiate voting as soon as possible (In two weeks). Thanks Etienne Kneuss for creating the first version of the RFC and the patch and others for discussing it. ~Hannes
Re: [PHP-DEV] [RFC] Weak References
Weak references is an OOP concept. Scalar data types and arrays are not OOP-related so I don't think that would make sense. Variable references is not the same as object references. A variable reference is simply a variable that is connected with another variable (if you set one it will change the other). If two variables have the same object reference they are not connected, if you set one variable the other is still set to the initial object reference. Also, arays and strings have special memory handling - they use lazy copying so it's opaque if two equal arrays/strings refer to the same region of memory. It's unclear what construction/destruction even mean in that sense. An array might actually have been constructed by the compiler. A reference to an object instance is a pointer but a reference to a variable is not. http://us.php.net/manual/en/language.references.arent.php I hope that illustrates the difference. Do you have any special use case in mind? ~Hannes On 18 July 2011 20:12, Adam Harvey ahar...@php.net wrote: This may just be Monday morning fuzziness, or I've just missed something in the RFC, but is there a reason weak references would be limited solely to objects, rather than any variable that can be dealt with by-reference? Thanks, Adam
Re: [PHP-DEV] [RFC] Weak References
Hi, Yes, I'm also interested in caching - It's a very interesting subject... borderline philosophical. When you are caching model instances in a database object relation layer you could clearly benefit from implementing some kind of caching mechanism that retains object even though it's unclear whether they actually need to be used (because you can't look into the future and known if the web application will select this ID again). I think it's bad design though to cache everything you can lay your hands on - memory usage is important. Also, database drivers and servers supply internal query caching. The programmer can achieve memory optimization caching by putting objects in a static variable if he knows he will need those objects later if the framework supplies internal weak-referencing. Trying to achieve this automatically with statistics and guessing would obviously not be as good a solution. But I stand by that weak references is not designed to solve this problem since it achieves the opposite - it removes caching - and it also solves other problems in other domains. If I was really looking for a solution to this caching problem I would instead suggest an RFC that supplied a cache where you could put objects in a recycle bin state instead with different priority levels when destructing. The GC would then be allowed to make intelligent decisions on whether to allocate more OS memory or deallocate objects in the recycle bin pool depending on total PHP memory usage, total system memory and object recycle bin priorities. A userland programmer could also be allowed to restore objects from the recycle bin on demand. But that would be a completely separate RFC. Feel free to make a draft if you like. ~Hannes And yes, my main concern is to keep it simple so SplWeakRef could be implemented as quickly as possible. On 18 July 2011 21:42, Lars Schultz lars.schu...@toolpark.com wrote: Hi Hannes, I think I like it after all;) What I don't understand is why you insist on WeakReferences not being about caching, when your first usecase clearly is at least related to caching. When mapping a DB-Record on a PHP-Object on-demand and then keeping it instead of recreating it every time you need it...of course you can argue it's not about caching because you'll be dropping it as soon as you're not using it anymore...but isn't that a deficiency rather than a different mechanism? As I've read in your quoted article SoftReferences are used for that kind of stuff...and I'd really be interested in that. But I guess your main concern is to keep it simple to make sure that it gets accepted into 5.4?... Thanks for the RFC and the proposal...it seems like a useful feature to me now. Cheers. Lars
Re: [PHP-DEV] weak references
On 17 July 2011 12:38, Ferenc Kovacs tyr...@gmail.com wrote: Hannes, now you should have karma for the rfc namespace, so you can now extend the article with your suggestions. Great, I'll start contributing ASAP. What's the next step after the RFC is complete? Testing? Voting? On 17 July 2011 15:04, Lars Schultz lars.schu...@toolpark.com wrote: I too would welcome a solution to this problem, I've run into it several times already and always had to use a semi-satisfactory solution. I hadn't heard about weak-references before, and I generally like the concept. What I am not so sure is wether this makes everything alot more complicated for users who do not know/care about the problem or the solution. Of course the impact on those users depends on the actual solution. If you are writing code that caches objects/relations and that caching has a significant impact on memory usage, you need to care about memory allocation/management per definition. So then you have to learn how OOP memory managment works (which should be obligatory anyway if you want to call yourself a OOP-developer IMO). A common argument to why programmers should not start with a garbage collected language is that it prevents them from understanding memory allocation concepts. I came at the problem from a different angle and came to a different solution: If I could get the refcount on a certain object, and kept the object stored centrally in one list, I'd know that if the refcount is down to 1 (or some other constant) that the object ist not in use anymore. I believe that this would be quite a simple PHP addition...a simple function called: get_ref_count() or something and as I remember, that value is always stored in the zval... The only other thing that would help would be a callback (or callable) which is triggered by PHP reaching a certain memory-limit, absolute or relative. Then I could clean up memory according to my own business-logic... This way, PHP would not feature something totally new, but one could still solve the problem with some work. Do I make any sense at all? Am I missing the point? Anyway, this is an interesting problem. Cheers. Lars It would probably be simple to implement such functionality. However this would be bad design since it would violate responsibility isolation. PHP should expose as little internal stuff to the userland as possible - unless there are a clear use case for it, and even then it might be a bad idea because it could cause BC breaks in future updates. If you write code that depend on reference counts or memory usage - you're doing something wrong. You either need data or you don't. If you need data you reference it. If you don't reference it the GC will deallocate it. A fundamental part of OOP is designing your program so you never reference stuff you don't need. Weak references solve the special case where you need the reference for as long as you need the data it references (as long as there are strong references for it). You should have a clear reference graph in your application - there is no magic solution to good object oriented design. The only scenario I could imagine where you could free memory spontaneously on demand (when the arbitrary OOM limit is reached) - is if that would be cached data. Caching is a very complicated subject that is not directly related to weak references. Start a separate thread about it and present clear use cases if you have anything special in mind. For example, I need weak references to store a table of back references between objects for later reference (depends on how you use the objects). If A references B i also need a weak reference from B to A so if B should be replaced with a C object I need the weak reference from B to A to know that A should be updated to point to C instead (if A still exists). This is not related to caching. ~Hannes
Re: [PHP-DEV] weak references
Hello, I just realized you could actually utilize the __destruct method to catch the event I described in my last post. The SplWeakRef class as currently defined in the RFC would therefore suffice to build a userland class that automatically garbage collects indexes. ~Hannes
Re: [PHP-DEV] weak references
I was going to add some content to https://wiki.php.net/rfc/weakreferencesnow but the wiki tells me that the page is read only for me. I couldn't find any details on who to contact to change this. ~Hannes
Re: [PHP-DEV] weak references
Since Weak references is already an established concept in many OOP languages a lot can be learned from their implementation. A lot of the potential related problems and solutions has already been studied. Anyone who wish to contribute to this feature should start by reading this excellent article by Ethan Nicholas: http://weblogs.java.net/blog/2006/05/04/understanding-weak-references For example I previously stated that I wanted a callback to clean up the weak reference object and indexes in the collection - then came to the conclusion that __destruct method would suffice for this. Then I read this part: quote Reference queue Once a WeakReference starts returning null, the object it pointed to has become garbage and the WeakReference object is pretty much useless. This generally means that some sort of cleanup is required; WeakHashMap, for example, has to remove such defunct entries to avoid holding onto an ever-increasing number of dead WeakReferences. The ReferenceQueue class makes it easy to keep track of dead references. If you pass a ReferenceQueue into a weak reference's constructor, the reference object will be automatically inserted into the reference queue when the object to which it pointed becomes garbage. You can then, at some regular interval, process the ReferenceQueue and perform whatever cleanup is needed for dead references. /quote Java utilizes a ReferenceQueue that tracks dead references so you can process and clean up dead references which is an excellent design solution. The Queue part is not that important, the references might as well be organized in a LIFO than a FIFO but a FIFO conceptually more fitting. Imaging dead references standing in a queue, awaiting cleanup. The solution is also superior to the __destruct solution since you would have to extend or modify the class and override the __destruct method. It makes it impossible to separate the how the instances is externally stored-design from the actual class itself, ergo: you can't cache classes in external libraries without hacking the libraries. I therefore propose changing the constructor (and implementation) to: void SplWeakRef::__construct(object ref, SplQueue ref_queue = null) If the SplWeakRef is given a ref_queue, it will call ref_queue-push($this) whenever it becomes invalid. If additional cleanup is required (if you want to catch the event and do cleanup immediately) one could simply extend SplQueue and overload SplQueue::push(). Note that resurrection must be avoided so the SplWeakRef does not flip between valid - invalid and then turns valid again (this would be a confusing behavior which can lead to unintentional behavior = bugs). The implementation should therefore make sure the SplWeakRef does not turn invalid before __destruct has been run for the object since __destruct can resurrect an object. ~Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
I'm not familiar with the internal implementation of GC in PHP but if the current garbage collection implementation makes catching the gc event non-trivial I'd agree and vote for postponing my SplQueue ref_queue suggestion until the future. It could always be added later and there is the temporary __destruct workaround for the meantime. ~Hannes On 16 July 2011 13:23, Ferenc Kovacs tyr...@gmail.com wrote: Etienne Kneuss has more knowledge about the implementation, but AFAIK as we didn't modified the garbage collector we didn't get notified if a weakreferenced object gets gced, so we can't notify the SplQueue either. please be aware that the bigger the change that we introduce it is less likely that we can make this happen in 5.4, or at all. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
Hi, Ferenc: Good idea to move the discussion to a separate thread. Etienne: Awesome. I wish I had time to write the patch myself. I could probably put some hours into adding more details to the RFC though. The only problem as I see it by making it a weak reference class instead of a weak reference collection is that you would end up with a bunch of unnecessary indexes in the array that points to invalid references. The simplest solution to this problem if you still want to implement it as you have begun to is to allow catching the cleanup event in a callback so you can manually unset the index. Should I add these concerns to the RFC? Thanks a bunch, Hannes
Re: [PHP-DEV] [VOTE] 5.4 features vote
Hello, Is it possible to add Weak References to this todo list? https://bugs.php.net/bug.php?id=52318 I've been waiting over a year now for this feature. It's a critical part of object relational layer mapping and my framework will be broken until it exists. One of our important customer projects also broke down because my current work around (simply using an array) leaks huge amounts of memory due to automatic instance caching similar to the one in the example I typed down below. I'm also considering switching language since PHP lacks this important OOP concept. There does not yet seem to be an RFC for it so I typed down an example that attempts to look like real-word usage here: http://pastebin.com/pCHVK0L8 I esteimate that it's pretty simple to implement the theoretical SplWeakArray in the example I wrote if you have a bit of knowledge about the internals of PHP referencing and garbage collection. See the Java WeakReference for conceptual reference. http://download.oracle.com/javase/1.4.2/docs/api/java/lang/ref/WeakReference.html A copy of WeakReference would be a partial solution for me since I rather need a dictionary of id's mapped to objects. I don't want to go trough an array all the time and look for indexes that has been set to NULL. That's the GCs job. Hence the SplWeakArray class. ~Hannes
Re: [PHP-DEV] [VOTE] 5.4 features vote
Okay, maybe it could be attempted to be squeezed in anyway to 5.4? I really need this feature and apparently others feel the same way. - It would benefit MVC framework design - one of the most common design pattern for web development. - The ticket has been open for over a year now and it has a lot of votes and high score. (High priority.) - It's not especially complex. (Easy to implement.) - It's not a language construct. (Non-controversial.) - It's already implemented in other OOP languages and has been extensivly researched. (Non-controversial.) - It could be implemented by adding a single additional Spl class. (Easy to implement.) ~Hannes On 14 July 2011 20:22, Stas Malyshev smalys...@sugarcrm.com wrote: Probably not for 5.4.0. This looks like a thing that needs an RFC and discussion (and implementation of course ;). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
[PHP-DEV] 32 bit / 64 bit integer confusion
Greetings. One very important feature of PHP is its interoperability. This allows my colleagues to work in both Windows, Ubuntu and OSX - developing the same application. Details like the fact that PHP will replace forward slash with backward slash automatically in windows is a great example of that. As a developer it's very important for me that the code executes exactly the same - no matter if the script is running on my development machine or in the production server. This is true for many other scripted languages. In javascript for example I expect an integer addition to return the same result - no matter the platform. At this point PHP is currently problematic since it for some reason - defines the integer size to depend on the current platform the code is running on which make no sense at all in my eyes. What are the reasoning behind this? I think the PHP integer size should be changed to always be 64 bit - independent of the platform. I have stumbled on this annoying inconsistency several times the last month. One specific use case for me where this causes problems is that I have integer ID columns in my database. I fully expect those to overflow above 2.1 billion at some point so then I suddenly have to be concerned if PHP is 32 or 64 bit compiled. Also, telling developers that an integer always supports 64 bit will make life much easier for them when they need it for implementing large numbers in cryptography, date arithmetics, scientific values, API interaction, etc etc. ~Hannes
Re: [PHP-DEV] 32 bit / 64 bit integer confusion
On 10 June 2011 16:54, Pierre Joye pierre@gmail.com wrote: The sad part is not that windows uses a consistent type size across architecture but that linux and gcc considers that a type could be whatever the architecture uses. Hence why stdint.h was introduced and should be used instead of the long/int. Find/replace int - int64_t. Problem solved. ;) ~Hannes
[PHP-DEV] Inline constructing/cloning and inline foreach listing
Hi,
I like to do stuff inline instead of cluttering my code with variables.
There are currently three syntaxes/expressions which are currently not
supported but I hope could be implemented until 5.4.
First inline constructing (which I think has already previously been
discussed), but also cloning, e.g:
// Inline constructing:
$car = (new CarFactory())-makeCar();
// Inline cloning:
$tomorrow = (clone $today)-add($one_day);
I'd also like to iterate sets of arrays more inline: (I'm not sure if this
has been discussed before)
foreach ($arrays as list($e1, $e2, $e3)) { ...
// Instead of:
foreach ($arrays as $array) {
list($e1, $e2, $e3) = $array;
Regards,
Hannes
Re: [PHP-DEV] Inline constructing/cloning and inline foreach listing
On 7 June 2011 15:53, John Crenshaw johncrens...@priacta.com wrote:
foreach ($arrays as list($e1, $e2, $e3)) { ...
Disagree. This feels very obtuse. I wouldn't expect this construct to work
at all, and even if it did, it is highly ambiguous (I.E. at first I thought
you were intending to grab 3 entries at a time, rather than extracting
entries from a second array).
John Crenshaw
Priacta, Inc.
I don't understand what's ambiguous? For each iteration the foreach assigns
the current value to the variable $value specified as either as $key =
$value or as $value. The as keyword is simply a type of assignment
operator that assigns the current element to the right expression. Since PHP
has a special list() language construct for assignment it doesn't make
sense that list(...) = $something assignment would work but not
array($something) as list(...).
Grabbing 3 elements at a time is not logical at all. Why would the list
construct change how the foreach iterates?
Hannes
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
+1 ~Hannes
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
I don't there's a good general case for this. I'd +1 on throwing E_NOTICE. Hannes On 2 June 2011 13:54, Hannes Magnusson hannes.magnus...@gmail.com wrote: How about making it useful rather then just throwing an notice? Recursive implode maybe? Or json/php serialized? :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing some cruft
Yeah, I was wondering why the magical logo thing was implemented like that. Just use the href= data:image/png;base64,... scheme instead if you really need a logo there. Combine that with smaller size and heavy jpeg compression and it shouldn't make the HTML /that/ bloated. Hannes If you really need such content in phpinfo() you could simply embed the picture in HTML using the data: scheme. On 31 May 2011 15:57, Philip Olson phi...@roshambo.org wrote: On May 28, 2011, at 10:42 AM, Daniel Brown wrote: On Sat, May 28, 2011 at 06:05, Kalle Sommer Nielsen ka...@php.net wrote: expose_php = Off? I think what he and others mean is that they want the option to leave the logo, credits, et cetera, completely out of the build at compile time. We also have other possibilities here (this is not a proposal, but rather, a list of options/ideas to ponder): 0. Do nothing 1. Disable expose_php within the distributed php.ini-* files Trivial, but changing [at least] php.ini-production is a real possibility. 2. Disable expose_php by default within PHP We could do this too. Default === when no php.ini file is used. 3. Remove the specific PHP version from the exposed PHP header There are security concerns although I'm not sure what implications (BC?) or real help this would offer. For example, version information can be deciphered by other means (e.g., logos and credits change over time) but maybe it's a help because, for example, displaying phpinfo() requires direct user action. See also #4. 4. Change its behavior and usage For example, phpinfo() relies upon expose_php for both the logo and credits information to be displayed. However, the phpinfo() output clearly exposes PHP (along with the version) regardless of the expose_php setting so we could instead embed the logo into phpinfo(), and display credits as per phpcredits(), instead of relying upon expose_php for this as done currently. In other words, expose_php could be off yet phpinfo() behavior would remain close to the same with either a little extra markup, or appended credits near the license. But this raises the question: Why do we have magical logo and credit guids? 5. And a performance review People are concerned with performance issues (e.g., images loaded into memory) although I'm not sure what real performance is lost (some have made guesses). Is there a real issue with performance here? How does it compare with, let's say, loading an additional extension? If so, how can it be helped? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] INF behavior
Agree with Derick, strictly speaking, in maths science, INF != INF. I disagree,based on quote from http://compilers.iecc.com/comparch/article/98-07-134: Since a projective infinity doesn't have a sign, comparing a floating point value other than infinity to a projective infinity is unordered. However, a projective infinity is equal to itself. Hannes On 31 May 2011 21:39, Julien Pauli jpa...@php.net wrote: Agree with Derick, strictly speaking, in maths science, INF != INF. But I dont care if PHP tells me than yes, because PHP is not designed to solve high level maths problems :) Cheer, Julien.Pauli On Fri, May 27, 2011 at 4:48 PM, Derick Rethans der...@php.net wrote: On Thu, 26 May 2011, Scott MacVicar wrote: On 26 May 2011, at 20:03, Philip Olson phi...@roshambo.org wrote: Hello geeks, A geek is needed to clarify PHP bug #45712. This is an edge case but the test (bug45712.phpt) contains code similar to the following: ?php $inf = pow(0, -2); var_dump($inf); // float(INF) var_dump($inf == $inf); // bool(false) var_dump($inf === $inf); // bool(true) ? That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true. Is this is how we want it? And how should this be documented/explained? I think I changes this :-) It didn't make sense that == and === produce different results. Though if someone has a better understanding of maths then we can fix it. I think it does make sense. == is the equal operator, and INF is not equal to INF (just like SQL NULL is not equal to NULL). However, they are identical (like you can test in SQL with NULL IS NULL). cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- 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] Implicit isset/isempty check on short-ternary operator
I was planning on replying to the coalesce suggestion but you really took
my concerns and stated them much better than I could have myself, plus a
couple of other concerns I didn't even think about.
To respond to Arpad Ray's statement:
To elaborate, I'd probably think this code was an unlikely series of typos,
or an encoding error:
In my opinion that's a good thing. Then you might actually look it up in the
documentation instead of making the assumption that the syntax has
function-like properties just because it looks like a function. For example,
it took me at least 1 year from first encountering empty() until
understanding that it's not a normal function and actually a language
construct that suppresses unset notices. And I'm a pretty seasoned
programmer. There's only one thing worse than magic: hidden magic.
~Hannes
On 23 April 2011 05:05, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote:
It's good for some situations, but there are plenty more where it doesn't
cut it, e.g. $_GET[?'foo'] $:= get_default_from_db('foo') $: hard-coded.
Ben.
Re: [PHP-DEV] Function proposal: varset
This discussion is equivalent to the one that we just had. Read the thread [PHP-DEV] Implicit isset/isempty check on short-ternary operator. Also the $var = var_set($_GET['var'], $_POST['var'], 'default'); syntax you propose would be equivalent to (as per previous discussion): $var = $_GET[?'var'] $: $_POST[?'var'] $: 'default'; (The syntax might also be [?'var'], ['var'?] or different). On 20 April 2011 18:19, Alain Williams a...@phcomp.co.uk wrote: On Wed, Apr 20, 2011 at 11:06:47AM -0500, Brian Moon wrote: It might be nice to extend it such that if the 1st argument is a list then the first in the list which is set is returned, eg: $var = var_set(($_GET['var'], $_POST['var']), 'default'); If that is the usage, I would suggest coalesce() to be consistent with the same concept in SQL. And you would not need a list as the first argument. Just pass multiple arguments and return the first set value. $var = var_set($_GET['var'], $_POST['var'], 'default'); Even better. http://en.wikipedia.org/wiki/Null_%28SQL%29#COALESCE -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
I like this - especially .7 and .8.
The $: is intuitive because it looks like a variable that doesn't contain
anything and the : specifies what comes then.
However I'd rather use the ? character than @ for the simple reason that
I see this as a more careful way to access an array and not as an error
silencing operation. E.g. it's not implemented by setting error reporting
to 0 but rather... to illustrate it, let's pretend that the PHP array where
implemented by the ArrayAccess class. The offsetGet signature would be
changed too take an extra argument:
offsetGet( mixed $offset, boolean $unset_defined )
Normal array access would have $unset_defined set to false, but an access
like $a?[$k] would set it to true (the ?[ modifier) would make
$unset_defined become true so:
if (!$unset_defined) {
\trigger_error(Undefined index: $offset, \E_NOTICE);
}
return null;
Of course, in userland, one could implement ArrayAccess and exploit the
$unset_defined parameter in any other way. Let's for example say that you
implement it to make an ArrayAccess class that maps data to the file system,
using the file name as a $offset. If $unset_defined is set to false you
would just go ahead and try to open the file in question, possibly raising a
file operation error - however if $unset_defined is true you might make a
careful check before opening the file to see if it really exist. If error
silencing would be used instead - other errors like file permission errors
could incorrectly be silenced - but $unset_defined specifically checks if
the file exist or not before access. So it could affect the read operation
itself - and I hope that explains why It's more than just error silencing.
~Hannes
On 15 April 2011 03:01, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote:
I agree empty() is basically useless. We already have the existing
ternary operator (and its shortcut) to do a boolean test, which is
basically the same as empty().
The way I see it, if rather than making an isset() operator that
suppresses errors and offers a default, we added both a !==null operator
for the default, and a separate error-suppression mechanism, people
could use the suppression mechanism with the existing boolean ternary
operator if they want to (I would find that useful, as I often write
things such as isset($a[$k])$a[$k]?yes:no for that kind of thing),
and use the !==null operator without error suppression (I would find
that useful, too, to avoid typos).
In summary, with two separate, simpler mechanisms, we could tackle these
paradigms (I have used @[...] for undefined index error-suppression and
$: for !==null default):
1. $v!==null ? $v : default
$v $: default
with notice
2. $a[$k]!==null ? $a[$k] : default
$a[$k] $: default
with notice
3. isset($a[$k]) ? $a[$k] : default
$a@[$k] $: default
without notice
4. isset($a[$k]) ? $a[$k] : null
$a@[$k]
without notice
5. isset($a[$k])!!$a[$k]
!!$a@[$k]
without notice
6. isset($a[$k])$a[$k] ? yes : no
$a@[$k] ? yes : no
without notice
With !==null assignment (I've used $:=) we could also have:
7. if (!isset($a[$k])) $a[$k] = default;
$a[$k] $:= default;
without notice (the LHS of an assignment never generates one)
To avoid encouraging poor coding, we would deliberately not have:
8. isset($v) ? $v : default
$@v $: default
without notice
But it is a cinch to add it if enough people want it, and doing so
wouldn't affect anyone who didn't want to use it--no backward
compatibility problems on the horizon. I think that's the clincher. If
we just add an isset() operator (that suppresses errors, and gives a
default), we only get paradigms 3, 4, 5 and maybe 7, but worse, if we
want to add any of the others later, we need to design more complicated
new operators, or break backward compatibility, not just extend what we
have.
I personally use 1, 3, 5 and 6 quite often, and 2 and 7 occasionally, so
I see great value in being able to do them all, not just the restricted
set.
What numbers are others interested in being able to solve?
What do others think about the future-proofing issue?
Ben.
On 15/04/11 1:01 AM, Hannes Landeholm wrote:
I can agree that implementing ?? with isset() and not array_key_exists()
would be
acceptable... but empty() is a blunt compromise and much less used... The
general
problem is the notice being thrown when array indexes doesn't exist -
which
results in code duplication when you deal with it nicely. empty() tries to
be a
generic solution but there will always be people that has some other
special
definition of emptiness like array that contains a single null value
and they
need to write the code that defines that particular comparison anyway.
You can't have a solution that makes everything easier for everyone so
let's solve
one thing at a time and start with the most generic problem specifically
and not
all minor problems that happens to partially intersect
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Trying to summarize this discussion... I think we can all agree that the main problem is code duplication for array access when parameters are possibly not existing. I think we all can also agree that @ can be both used properly and misused - and it is a blunt tool and not a nice solution to the previously stated problem. Some suggested that the ternary if comparison should suppress the notice automatically. This would break existing code and also be confusing since people expect a ternary if and normal if to work the same way. Some suggested ?? as an array access operator that suppresses the notice and has 3 variants: A: nothing specified - uses null as default, B: has default specified, C: returns X if index exists or Y if index doesn't exist. This effectively solves the code duplication problem and is a shortcut for saying the array index may or may not exist. One person said that the relation between ? and ?? and == and === would make the operator non-intuitive. Other people disagreed and claimed the opposite. So basically the discussion now is what exact characters that should be used to represent this operator? I really hope we can get this implemented quickly... I worked with $_POST yesterday and I could really use that ?? operator. ~Hannes
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
I can agree that implementing ?? with isset() and not array_key_exists() would be acceptable... but empty() is a blunt compromise and much less used... The general problem is the notice being thrown when array indexes doesn't exist - which results in code duplication when you deal with it nicely. empty() tries to be a generic solution but there will always be people that has some other special definition of emptiness like array that contains a single null value and they need to write the code that defines that particular comparison anyway. You can't have a solution that makes everything easier for everyone so let's solve one thing at a time and start with the most generic problem specifically and not all minor problems that happens to partially intersect that one. ~Hannes On 14 April 2011 16:26, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote: On 15/04/11 12:05 AM, Hannes Landeholm wrote: Trying to summarize this discussion... I think we can all agree that the main problem is code duplication for array access when parameters are possibly not existing. For me the problem is 'code duplication when a value might be null' (whether an array, variable or something else, and regardless of whether it was set to null, or not defined at all). I think we all can also agree that @ can be both used properly and misused - and it is a blunt tool and not a nice solution to the previously stated problem. Yes. Some suggested that the ternary if comparison should suppress the notice automatically. This would break existing code and also be confusing since people expect a ternary if and normal if to work the same way. Yes. Some suggested ?? as an array access operator that suppresses the notice and has 3 variants: A: nothing specified - uses null as default, B: has default specified, C: returns X if index exists or Y if index doesn't exist. This effectively solves the code duplication problem and is a shortcut for saying the array index may or may not exist. This only works if the test is made an isset() kind of test. If it remains a boolean cast, it doesn't help much. (Or at least it doesn't help me much.) I also think it's a bit too blunt. In all but the simplest expressions in the condition, desired notices could be silenced. I like the idea of being able to specify exactly which array lookups should be silenced. It also doesn't help the people who want an isset() style test, but without the notice suppression, and I think there are a few people in that category. One person said that the relation between ? and ?? and == and === would make the operator non-intuitive. Other people disagreed and claimed the opposite. So basically the discussion now is what exact characters that should be used to represent this operator? I really hope we can get this implemented quickly... I worked with $_POST yesterday and I could really use that ?? operator. I still don't think we've reached agreement on exactly what we need. Your summary seems to me to be of some of the earliest and least developed ideas. I think the discussion has moved in a number of interesting directions since then and we should draw on that later work. Ben.
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Nope. I prefer to treat invalid or non existing basic types as them being set to a default value. This makes the input handler very robust and I don't have to waste time by writing code that handles failed validation. For example if I read an integer from $_POST I'd simply write: $value = \intval(@$_POST[field]); (or a boolean:) $value = (@$_POST[field] == set); I'd prefer this syntax though: $value = \intval($_POST[field]??); ..simply because it's a more precise expression and no notice is generated and have to be ignored when running the custom error handler - so it should be faster too. ~Hannes On 14 April 2011 18:08, Ole Markus With olemar...@olemarkus.org wrote: On Thu, 14 Apr 2011 16:05:45 +0200, Hannes Landeholm landeh...@gmail.com wrote: So basically the discussion now is what exact characters that should be used to represent this operator? I really hope we can get this implemented quickly... I worked with $_POST yesterday and I could really use that ?? operator. When it comes to $_POST you probably want to use filter_input instead. Cheers, Ole Markus With
Re: [PHP-DEV] proposed access modifier silent ... was: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
@ is not convenient since it turns off error reporting for all errors. I don't know how many times I've silenced a notice and got a blank page in my face as a thank you for accidentally silencing that fatal error too. Silent is reserved for the purpose of the silence operator though @ so using that as a keyword for something else would be confusing. It just struck me that the ~real~ problem is that sometimes you want array access that should define undefined indexes as being null (a good placeholder for this purpose). How about (instead of the previously proposed ?? and isnotempty and whatnot) simply changing the array access syntax to simply allow an optional ? operator at the end signaling that the condition where the index isn't defined isn't unexpected? For example: $value = isset($arr[foo])? $arr[foo]: null; $value = isset($arr[$foo])? $arr[$foo]: null; would be replaced with: (respectively) $value = $arr[foo?]; $value = $arr[$foo?]; it would also worked chained: $value = $arr[foo?][bar][baz?] (if [foo] doesn't exist value will be null.. if [foo] exists [foo][bar] is expected to exist but [foo][bar][baz] may or may not exist... if not, value will once again be null) This way it would only apply to array access which was a +1 for some. This could also be extended too replace null with something different (by allowing an expression after the ? like null or foo . bar) but I think careful use-case research should be done to determine if it's really needed first... I realize this partially collides with the use of ? so it would be more difficult to implement but it's far from impossible.. it just requires a little ahead-parsing in brackets [] to know if the ? is a ternary if or if it's a not exists is not undefined operator (is the : missing or not?). Otherwise ?? could simply be used instead or a completely different operator... ~Hannes On 11 April 2011 04:47, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! @. Note however it does not exactly turn off the warning, only changes it to not reported. It's still generated and can be picked up by handlers, for example. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Hi. I like Adam's suggestion _a lot_ however I'd also find a third case very useful. In addition to: * // standard $value = isset($a[$key]) ? $a[$key] : 'Not set'; // new ?? double ternary that performs isset check and omits second expression $value = $a[$key] ?? : 'Not set'; // new ?? double ternary that performs isset check and uses second expression $value = $a[$key] ?? strtoupper($a[$key]) : 'Not set'; * I would also like a case where you could: // new ?? double ternary that performs isset check and uses null $value = $a[$key]??; This would replace a lot of ugly code I have where: (the @ operator is ugly) $value = @$a[$key]; When I want to treat all non existing indexes as containing the null value. ~Hannes On 8 April 2011 09:02, Adam Richardson simples...@gmail.com wrote: We need to be careful about changing the beahviour of existing operators. Indeed. The '?' character already is special, so using '??' seems like a safe, practical approach. However, I'd prefer maintaining the form of the standard ternary operator with the colon ($value = $var['bar'] ?? : 'Bar was not set'; // value =Bar was not) so the '??' operator could be applied in any situation that one would normally use the standard ternary operator. // standard $value = isset($a[$key]) ? $a[$key] : 'Not set'; // new ?? double ternary that performs isset check and omits second expression $value = $a[$key] ?? : 'Not set'; // new ?? double ternary that performs isset check and uses second expression $value = $a[$key] ?? strtoupper($a[$key]) : 'Not set'; Granted, the last example might be infrequent, but I think there's also a value in keeping the form of the double ternary (if used at all) the same as the standard ternary operator for consistency sake. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
I think ?! wouldn't work as an operator as it would conflict with ternary
comparision + not operator. Also I don't see the point of adding an operator
for empty as the function/construct itself is pretty confusing and
non-useful as you have to memorize all the things that happen to be
considered empty by it and those things has too align up with the things
you want to check for by chance. (I never use it.)
Empty-ness is just one of a billion things you might want to write a
comparison for (and it's not even well defined). Having an operator for that
would be crazy. Dealing with possibly undefined indexes/properties is a very
common use case though which is why I think it deserves an operator. The
empty comparison thing is a _separate issue_ and it can simply be dealt
with by separating the assignment and comparison into two expressions...
~Hannes
On 8 April 2011 15:19, Rune Kaagaard rumi...@gmail.com wrote:
Dear Internals
I'm very happy that this is getting some attention again. Please allow
me to give my 2 cents too. The text below can also be seen nicely
formatted at https://gist.github.com/909711.
## Intro ##
Isset and IsNotEmpty operators have for sure been a hot topic for several
years
now and in my opinion rightly so. The non-DRY style of:
$my_array['my_long_boring_key'] =
!empty($my_array['my_long_boring_key'])
? $my_array['my_long_boring_key'] : 'Default value';
$my_array['my_long_boring_key'] = isset($my_array['my_long_boring_key'])
? $my_array['my_long_boring_key'] : 'Default value';
is a true day-to-day hassle and addressing this annoyance would be a
big win for
the PHP community as a whole. As PHP has two keywords `isset` and `empty`
that
can check for a non existing variable without throwing errors I think there
should exist two assignment/ternary operators who mirror those.
I have been thinking [1] about the same problem for my meta language Snow
and
also ended up using `??` as an isset operator.
## Proposal ##
I propose that two new operators `??` (IssetOperator) and `?!`
(NotEmptyOperator) are added. `??` mirrors `isset` and `?!` mirrors
`!empty`.
They are chainable ad nauseum but not with each other.
They would work like this:
### Example 1 : Ternary shortcut ###
Old syntax:
$a = isset($b) ? $b : 42;
$a = !empty($b) ? $b : 42;
New syntax:
$a = $b ?? 42;
$a = $b ?! 42;
### Example 2 : Direct assignment ###
Old syntax:
$arr['key'] = isset($arr['key']) ? $arr['key'] : 42;
$arr['key'] = !empty($arr['key']) ? $arr['key'] : 42;
New syntax:
$arr['key'] ??= 42;
$arr['key'] ?!= 42;
### Example 3 : Works with statements too ###
Old syntax:
// a)
$tmp = get_stuff('foo');
$a = isset($tmp) ? $tmp : 42;
// b)
$tmp = get_stuff('foo');
$a = !empty($tmp) ? $tmp : 42;
New syntax:
// a)
$a = get_stuff('foo') ?? 42;
// b)
$a = get_stuff('foo') ?! 42;
### Example 4 : Chaining ###
Old syntax [2]:
$a = false;
if (!empty($c) {
$a = $c;
} else {
$tmp = get_stuff();
$a = !empty($tmp) ? $tmp : false;
}
if ($a === false) {
$a = !empty($c) ? $c : 42;
}
New syntax:
$a = $c ?! get_stuff() ?! $b ?! 42;
### Example 5 : Illegal syntax ###
$a = $d ?? $c ?! $b ?? 42; // `??` and `?!` cannot be mixed.
## References ##
* [1]: http://code.google.com/p/php-snow/wiki/EmptyIssetOperators
* [2]: This could also be done by nesting ternary operators, but that
gets
even more unreadable I think.
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Operators should have very specific purpose and function... a ternary if
statement should just be another way to express a normal if statement.
Making the ? operator suppress the not defined error would be a poor
compromise, making PHP inconsistent. Then I'd rather have access of
non-defined array indexes return null instead (simply removing the
not-defined notice for arrays - where array_key_exists and isset would still
work like normal if you want to check for undefined).
~Hannes
On 8 April 2011 16:45, Martin Scotta martinsco...@gmail.com wrote:
I just feels that !empty($arr['key']) or isset($arr['key']) do not express
the real meaning, instead I would choose to write array_key_exists('key',
$arr). It may be slower but it clearly express what I meant.
Regarding the operators, I believe they will do more harm than good.
To check if a variable was already defined is a bad programing habit, these
operators will encourage that kind of things
In the other hand, the isset check inside the condition ?: would silently
improve not-so-well written code, and could be a good feature for the lang.
Martin Scotta
On Fri, Apr 8, 2011 at 11:27 AM, Hannes Landeholm landeh...@gmail.comwrote:
I think ?! wouldn't work as an operator as it would conflict with
ternary
comparision + not operator. Also I don't see the point of adding an
operator
for empty as the function/construct itself is pretty confusing and
non-useful as you have to memorize all the things that happen to be
considered empty by it and those things has too align up with the things
you want to check for by chance. (I never use it.)
Empty-ness is just one of a billion things you might want to write a
comparison for (and it's not even well defined). Having an operator for
that
would be crazy. Dealing with possibly undefined indexes/properties is a
very
common use case though which is why I think it deserves an operator. The
empty comparison thing is a _separate issue_ and it can simply be dealt
with by separating the assignment and comparison into two expressions...
~Hannes
On 8 April 2011 15:19, Rune Kaagaard rumi...@gmail.com wrote:
Dear Internals
I'm very happy that this is getting some attention again. Please allow
me to give my 2 cents too. The text below can also be seen nicely
formatted at https://gist.github.com/909711.
## Intro ##
Isset and IsNotEmpty operators have for sure been a hot topic for
several
years
now and in my opinion rightly so. The non-DRY style of:
$my_array['my_long_boring_key'] =
!empty($my_array['my_long_boring_key'])
? $my_array['my_long_boring_key'] : 'Default value';
$my_array['my_long_boring_key'] =
isset($my_array['my_long_boring_key'])
? $my_array['my_long_boring_key'] : 'Default value';
is a true day-to-day hassle and addressing this annoyance would be a
big win for
the PHP community as a whole. As PHP has two keywords `isset` and
`empty`
that
can check for a non existing variable without throwing errors I think
there
should exist two assignment/ternary operators who mirror those.
I have been thinking [1] about the same problem for my meta language
Snow
and
also ended up using `??` as an isset operator.
## Proposal ##
I propose that two new operators `??` (IssetOperator) and `?!`
(NotEmptyOperator) are added. `??` mirrors `isset` and `?!` mirrors
`!empty`.
They are chainable ad nauseum but not with each other.
They would work like this:
### Example 1 : Ternary shortcut ###
Old syntax:
$a = isset($b) ? $b : 42;
$a = !empty($b) ? $b : 42;
New syntax:
$a = $b ?? 42;
$a = $b ?! 42;
### Example 2 : Direct assignment ###
Old syntax:
$arr['key'] = isset($arr['key']) ? $arr['key'] : 42;
$arr['key'] = !empty($arr['key']) ? $arr['key'] : 42;
New syntax:
$arr['key'] ??= 42;
$arr['key'] ?!= 42;
### Example 3 : Works with statements too ###
Old syntax:
// a)
$tmp = get_stuff('foo');
$a = isset($tmp) ? $tmp : 42;
// b)
$tmp = get_stuff('foo');
$a = !empty($tmp) ? $tmp : 42;
New syntax:
// a)
$a = get_stuff('foo') ?? 42;
// b)
$a = get_stuff('foo') ?! 42;
### Example 4 : Chaining ###
Old syntax [2]:
$a = false;
if (!empty($c) {
$a = $c;
} else {
$tmp = get_stuff();
$a = !empty($tmp) ? $tmp : false;
}
if ($a === false) {
$a = !empty($c) ? $c : 42;
}
New syntax:
$a = $c ?! get_stuff() ?! $b ?! 42;
### Example 5 : Illegal syntax ###
$a = $d ?? $c ?! $b ?? 42; // `??` and `?!` cannot be mixed.
## References ##
* [1]: http://code.google.com/p/php-snow/wiki/EmptyIssetOperators
* [2]: This could also be done by nesting ternary operators, but
that
gets
even more unreadable I think.
Re: [PHP-DEV] Adding a more logical string slicing function to PHP
PHP's substr() is awesome and that comes from a person that code in at least
5 different languages daily. Parsing is a problem in many real-world
problems and substr currently works great for that purpose. You work with
two parameters: offset and length of parsing. Since meaning of a negative
offset/length when sub-stringing is intuitively undefined, PHP has reserved
these ranges for two common usecases: offsets from the end of the string and
truncation length.
I just think it is very unintuitive for the first parameter always to be a
position, and the 2nd parameter to be a length if the value is positive, and
a position if the value is negative.
The first parameter is either an offset from start or offset from end - the
second parameter is either a length or a truncation length. I don't see why
this would be unintuitive? Perhaps you get confused by other languages that
just work with offsets.
In most real world parsing scenarios I've worked with offsets and lengths,
so the current substr definition gets my job done fastest without doubt.
Let's have a real world example Parse through the data in chunks of 64
bytes at a time. In PHP this is simple, just take the current offset and a
length of 64. In python you'd have to add 64 to the current offset and put
into the second offset parameter = you have to think more and write more
code instead of just working with the length directly.
Returning FALSE when start + length parameters are invalid. This is
annoying
because when using this function you always have to deal with this FALSE
case if
you need a string.
Guess what this code outputs?
var_dump((string) \substr(foo, 5, 6));
Now try this and you'll understand why this is basically never a problem
that substr outputs false and why you don't even have to think about it:
var_dump(\substr(foo, 5, 6) == , (string) false, false == );
Welcome to PHP. To be honest this criticism pretty much falls in the from
person that comes from another language X and is annoyed that every little
detail isn't exactly the same-category. Just make your own substr()
function that uses the behavior you expect if you don't like the native
version. Although that's bad practice - the best solution is to get used to
it. And if you have an urge to write about your experience with a new
language I suggest you do it in a blog instead of posting it in the
internals mailing list...
~Hannes
On 30 March 2011 09:42, Dan Birken bir...@gmail.com wrote:
I think when the values are positive everything is mostly great. I think
when the values are negative is where the main problems are. Both the C
function strncpy() and the C++ strings substr() function only support
positive values for length AFAIK.
I just think it is very unintuitive for the first parameter always to be a
position, and the 2nd parameter to be a length if the value is positive,
and
a position if the value is negative.
substr('string', 1, 2); // Goes from position 1 to position 3
substr('string', -2, -1); // Goes from position -2 to position -1
So here is the same kind of thing in python, which uses [start, end):
string[1:2] == 't'
string[-2:-1] == 'n'
And ruby, which uses [start, end]:
string[2..3] == 'tr'
string[-2:-1] == 'ng'
Both of these languages use positions for positive and negative values. In
addition, in both of these languages if you slice a string impossibly, both
of them return an empy string as opposed to false, which just seems more
intuitive to me.
I don't think this function is particularly novel, I just think both
returning an empty string on impossible slicing and slicing based on
positions are improvements, and combined I think this function is
noticeably
more durable and readable than substr().
-Dan
On Tue, Mar 29, 2011 at 11:22 PM, Lars Schultz lars.schu...@toolpark.com
wrote:
I just love substr() and I think all other languages got it wrong;)
Seriously...it behaves the same as implementations in other languages as
long as values are positive, right? how is that counter-intuitive? How do
other languages handle negative values?
Am 30.03.2011 08:06, schrieb Dan Birken:
My apologizes if I am bringing up a topic that has been discussed
before,
this is my first time wading into the PHP developers lists and I
couldn't
find anything particularly relevant with the search.
Here is a bug I submitted over the weekend (
http://bugs.php.net/bug.php?id=54387) with an attached patch that adds
a
str_slice() function into PHP. This function is just a very simple
string
slicing function, with the logical interface of str_slice(string, start,
[end]). It is of course meant to replace substr() as an interface for
string slicing.
I detailed the reasons I submitted the patch in the bug a little bit,
but
the main reason is that I think the substr() function is really overly
confusing and just not an intuitive method of string slicing, which is
exceedingly common functionality. I
Re: [PHP-DEV] Adding a more logical string slicing function to PHP
This thread shouldn't be a criticism of substr(), it would be pointless. Its signature and behaviour will never change, unless perhaps around April 1st as a practical joke on the millions of websites it would break. That's a really good joke actually. I can imagine how angry people would get. Maybe PHP could post it as a fake news update tomorrow? And yeah, I wouldn't mind an extra string slicing function although I think substr is sufficient... and if you're adding extra string functions there are more useful ones. These are the string functions in my PHP framework that I use regularly: // Already mentioned: starts_with($subject, $prefix) // returns bool ends_with($subject, $tail) // returns bool // Generating codes/ids: random_str($length = 16) // returns any string random_hex_str($length = 16) // returns any 0-9a-f random_alphanum_str($length = 16, $case_sensitive = true) // returns any a-z0-9/A-Z0-9 from_index($index) // 0 returns a, 1 returns b .. 3 = c.. n = z.. n + 1 = aa.. n + 2 = ab... // like base64 but only uses 0-9a-z (it encodes / as ad, + as ac and a as ab) base64_alphanum_encode($data) base64_alphanum_decode($str) // hex encodes string (eg. \x11\x1c = 111c) hex_encode($str) hex_decode($str) email_validate($email) // regex email validation (the actual regex is 390 characters and has never failed me... don't ask me how it works though) http_url_validate($url) in_range($string, $min = -1, $max = -1) // returns true if string has a certain length (easier to read and faster to write) quote($string) // for exporting any string to javascript escaping any escape or control characters automatically (e.g. \n) so foo\bar becomes exactly that ~Hannes On 30 March 2011 16:08, Josh Davis php...@gmail.com wrote: On 30 March 2011 15:05, Hannes Landeholm landeh...@gmail.com wrote: Parsing is a problem in many real-world problems and substr currently works great for that purpose. That's funny because the first thing I thought when I read the original mail was oh that would be great for parsing. In fact, I've just grep'ed through some code from a rich text parser I've been working on and at first glance there are at ~5 occurences of substr() that I would replace with str_slice(). There are also 15+ occurences of substr() that would remain untouched. It's not black-and-white, sometimes you want N characters starting from pos X, and other times you want to cut the text from pos X and pos Y, and that's where str_slice() would be welcome. This thread shouldn't be a criticism of substr(), it would be pointless. Its signature and behaviour will never change, unless perhaps around April 1st as a practical joke on the millions of websites it would break. The question is: is str_slice() useful, does it fill a need and should it be included into PHP? -JD
Re: [PHP-DEV] preg_replace does not replace all occurrences
What is more likely to be wrong? Your understanding of a specific
regex pattern (which happens to be full of escapes making it
incredibly hard to read) or the implementation of preg_replace?
~Hannes
On 14 March 2011 16:18, Martin Scotta martinsco...@gmail.com wrote:
I chose the simplest example to show the preg_replace behavior, there are
better (and safer) ways to scape slash characters.
Anyways, *is this the expected preg_replace behavior?*
Martin
?php
function test($str) {
static $re = '/(^|[^])\'/';
static $change = '$1\\\'';
echo $str, PHP_EOL,
preg_replace($re, $change, $str), PHP_EOL, PHP_EOL;
}
test(str '' str); // bug?
test(str \\'\\' str); // ok
test('str'); // ok
test(\'str\'); // ok
Expected:
str '' str
str \'\' str
str \'\' str
str \'\' str
'str'
\'str\'
\'str\'
\'str\'
Result:
str '' str
str \'' str
str \'\' str
str \'\' str
'str'
\'str\'
\'str\'
\'str\'
Martin Scotta
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] EOL removed after ?
http://brian.moonspot.net/php-history-newline-closing-tag ~Hannes On 10 March 2011 17:42, Martin Scotta martinsco...@gmail.com wrote: hi all, pre 1 ?php ; ?1 2 2 3 ?php ; ?3 /pre pre 1 1?php ; ? 2 2 3 3?php ; ? /pre First try works... but second fails output: 1 1 2 2 3 3 1 12 2 3 3 is this the expected behavior? Martin Scotta -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
I second making time limit reached catchable. All non catchable fatal errors
are a problem for me. I need to handle problems gracefully to ensure the
stability of production systems instead of PHP just killing itself without
warning. I just reported a similar issue:
http://bugs.php.net/bug.php?id=54195
A simple way to implement this would be to register a function that would be
called N seconds before the script would timeout.
register_timeout_handler(2, function() { die(PHP timed out.); });
It would be called just as a shutdown function - in fact I'd like to use the
same function as my shutdown function and get the error with
error_get_last(). Of course set_time_limit(0) could be used in this function
to prevent the timeout of the timeout handler. This does not prevent
timeout since set_time_limit could have been called by the script before the
timeout anyway.
On that note I also miss a function which returns the time the script can
keep running for. If that calculate needs to be calculated to implemented to
implement this, why not make the value available to the PHP script?
~Hannes
On 9 March 2011 02:30, David Muir davidkm...@gmail.com wrote:
Although it doesn't let you recover from a timeout, you could use
register_shutdown_function to gracefully exit after a fatal error.
register_shutdown_function(function(){
$error = error_get_last();
if($error $error['type'] === E_ERROR){
echo 'PHAIL! Oh noes, something went wrong!';
// do whatever else you need to do before quitting
}
});
Cheers,
David
On 08/03/11 22:39, Pierre Joye wrote:
hi,
is not the goal of this setting to prevent that a script runs longer
than a given time? A catchable error will prevent that to happen.
On Tue, Mar 8, 2011 at 2:05 PM, Sebastian Bergmann sebast...@php.net
wrote:
Could set_time_limit() be changed in such a way that it triggers a
catchable fatal error instead of a fatal error? Thanks!
--
Sebastian BergmannCo-Founder and Principal
Consultant
http://sebastian-bergmann.de/
http://thePHP.cc/
--
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] Make set_time_limit() timeout a catchable fatal error
I'm personally a fan of errors and well defined return values. Exceptions
doesn't solve any problem unless your problem is that your code is not
enough spaghetti-ish. But I agree with All fatal errors should be changed
to catchable fatal errors.
~Hannes
On 9 March 2011 15:18, Martin Scotta martinsco...@gmail.com wrote:
Fatal error are most dumb feature in the language.
The are lot of blind areas where you don't know if you will ever
return...
include file.php;
new Class();
call_func();
All fatal errors should be changed to catchable fatal errors so
applications will be able to recover themselves... and if they don't catch
the error... then die.
it would be nice if all errors could be changed into exceptions.
Martin Scotta
On Wed, Mar 9, 2011 at 10:56 AM, Hannes Landeholm landeh...@gmail.comwrote:
I second making time limit reached catchable. All non catchable fatal
errors
are a problem for me. I need to handle problems gracefully to ensure the
stability of production systems instead of PHP just killing itself without
warning. I just reported a similar issue:
http://bugs.php.net/bug.php?id=54195
A simple way to implement this would be to register a function that would
be
called N seconds before the script would timeout.
register_timeout_handler(2, function() { die(PHP timed out.); });
It would be called just as a shutdown function - in fact I'd like to use
the
same function as my shutdown function and get the error with
error_get_last(). Of course set_time_limit(0) could be used in this
function
to prevent the timeout of the timeout handler. This does not prevent
timeout since set_time_limit could have been called by the script before
the
timeout anyway.
On that note I also miss a function which returns the time the script can
keep running for. If that calculate needs to be calculated to implemented
to
implement this, why not make the value available to the PHP script?
~Hannes
On 9 March 2011 02:30, David Muir davidkm...@gmail.com wrote:
Although it doesn't let you recover from a timeout, you could use
register_shutdown_function to gracefully exit after a fatal error.
register_shutdown_function(function(){
$error = error_get_last();
if($error $error['type'] === E_ERROR){
echo 'PHAIL! Oh noes, something went wrong!';
// do whatever else you need to do before quitting
}
});
Cheers,
David
On 08/03/11 22:39, Pierre Joye wrote:
hi,
is not the goal of this setting to prevent that a script runs longer
than a given time? A catchable error will prevent that to happen.
On Tue, Mar 8, 2011 at 2:05 PM, Sebastian Bergmann sebast...@php.net
wrote:
Could set_time_limit() be changed in such a way that it triggers a
catchable fatal error instead of a fatal error? Thanks!
--
Sebastian BergmannCo-Founder and Principal
Consultant
http://sebastian-bergmann.de/
http://thePHP.cc/
--
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] Make set_time_limit() timeout a catchable fatal error
You mean the shutdown function is called and 1 nanosecond later PHP crashes
so you don't have time to do anything?
~Hannes
On 9 March 2011 15:27, David Muir davidkm...@gmail.com wrote:
Hmm, I think I worded that poorly.
A function registered with register_shutdown_function does execute when
the max_execution_time is exceeded.
What it doesn't let you do is to recover in the same way an error
handler would let you.
David
On 09/03/11 22:56, Hannes Landeholm wrote:
I second making time limit reached catchable. All non catchable fatal
errors
are a problem for me. I need to handle problems gracefully to ensure the
stability of production systems instead of PHP just killing itself
without
warning. I just reported a similar issue:
http://bugs.php.net/bug.php?id=54195
A simple way to implement this would be to register a function that would
be
called N seconds before the script would timeout.
register_timeout_handler(2, function() { die(PHP timed out.); });
It would be called just as a shutdown function - in fact I'd like to use
the
same function as my shutdown function and get the error with
error_get_last(). Of course set_time_limit(0) could be used in this
function
to prevent the timeout of the timeout handler. This does not prevent
timeout since set_time_limit could have been called by the script before
the
timeout anyway.
On that note I also miss a function which returns the time the script can
keep running for. If that calculate needs to be calculated to implemented
to
implement this, why not make the value available to the PHP script?
~Hannes
On 9 March 2011 02:30, David Muir davidkm...@gmail.com wrote:
Although it doesn't let you recover from a timeout, you could use
register_shutdown_function to gracefully exit after a fatal error.
register_shutdown_function(function(){
$error = error_get_last();
if($error $error['type'] === E_ERROR){
echo 'PHAIL! Oh noes, something went wrong!';
// do whatever else you need to do before quitting
}
});
Cheers,
David
On 08/03/11 22:39, Pierre Joye wrote:
hi,
is not the goal of this setting to prevent that a script runs longer
than a given time? A catchable error will prevent that to happen.
On Tue, Mar 8, 2011 at 2:05 PM, Sebastian Bergmann sebast...@php.net
wrote:
Could set_time_limit() be changed in such a way that it triggers a
catchable fatal error instead of a fatal error? Thanks!
--
Sebastian BergmannCo-Founder and Principal
Consultant
http://sebastian-bergmann.de/
http://thePHP.cc/
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
That's not a problem. Timeouts should be non-recoverable IMO as it's a
serious problem and I think most PHP developers would agree with this.
Making errors recoverable is difficult to implement, could have
performance penalties and be conceptually wrong when the state is defined as
never allowed to happen.
What I'm concerned about is that all problems should be able to be handled
gracefully from the register_shutdown_function like showing an informative
page, setting HTTP status, logging the problem, sending an error report,
etc. Not all fatal errors can be caught this way, including script timeout.
~Hannes
On 9 March 2011 15:39, Ferenc Kovacs i...@tyrael.hu wrote:
no, it only means that you cant return to the original scope and continue
the execution of your script.
as you can't throw exceptions also, because your code is running without a
stack frame.
you can check out the https://github.com/Tyrael/php-error-handler its a
little class which operates with register_shutdown_function to allow
handling non-recoverable errors before halting.
there are too many case in the php src where non-recoverable errors are
triggered for non fatal problems.
that should be changed, so open a bugreport if you think you found one,
where isn't neccessary to halt the execution.
Tyrael
On Wed, Mar 9, 2011 at 3:30 PM, Hannes Landeholm landeh...@gmail.comwrote:
You mean the shutdown function is called and 1 nanosecond later PHP
crashes
so you don't have time to do anything?
~Hannes
On 9 March 2011 15:27, David Muir davidkm...@gmail.com wrote:
Hmm, I think I worded that poorly.
A function registered with register_shutdown_function does execute when
the max_execution_time is exceeded.
What it doesn't let you do is to recover in the same way an error
handler would let you.
David
On 09/03/11 22:56, Hannes Landeholm wrote:
I second making time limit reached catchable. All non catchable fatal
errors
are a problem for me. I need to handle problems gracefully to ensure
the
stability of production systems instead of PHP just killing itself
without
warning. I just reported a similar issue:
http://bugs.php.net/bug.php?id=54195
A simple way to implement this would be to register a function that
would
be
called N seconds before the script would timeout.
register_timeout_handler(2, function() { die(PHP timed out.); });
It would be called just as a shutdown function - in fact I'd like to
use
the
same function as my shutdown function and get the error with
error_get_last(). Of course set_time_limit(0) could be used in this
function
to prevent the timeout of the timeout handler. This does not prevent
timeout since set_time_limit could have been called by the script
before
the
timeout anyway.
On that note I also miss a function which returns the time the script
can
keep running for. If that calculate needs to be calculated to
implemented
to
implement this, why not make the value available to the PHP script?
~Hannes
On 9 March 2011 02:30, David Muir davidkm...@gmail.com wrote:
Although it doesn't let you recover from a timeout, you could use
register_shutdown_function to gracefully exit after a fatal error.
register_shutdown_function(function(){
$error = error_get_last();
if($error $error['type'] === E_ERROR){
echo 'PHAIL! Oh noes, something went wrong!';
// do whatever else you need to do before quitting
}
});
Cheers,
David
On 08/03/11 22:39, Pierre Joye wrote:
hi,
is not the goal of this setting to prevent that a script runs longer
than a given time? A catchable error will prevent that to happen.
On Tue, Mar 8, 2011 at 2:05 PM, Sebastian Bergmann
sebast...@php.net
wrote:
Could set_time_limit() be changed in such a way that it triggers a
catchable fatal error instead of a fatal error? Thanks!
--
Sebastian BergmannCo-Founder and Principal
Consultant
http://sebastian-bergmann.de/
http://thePHP.cc/
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
Yes, it's possible to measure the time left yourself. However
set_time_limit documentation states that not all time are accounted for when
measuring how long the script can run for. If it's a UNIX system and you're
using system operations/database queries etc there will be a difference
between the time you measure the script has run for and the time PHP has
measured.
And this is only a suitable solution in controlled code like when you're
doing something defined in a loop and can measure the time with regular
intervals. I need it for my framework which can contain any kind of logic,
even logic that uses set_time_limit by itself.
~Hannes
On 9 March 2011 15:52, Thomas Hruska thru...@cubiclesoft.com wrote:
On 3/9/2011 6:56 AM, Hannes Landeholm wrote:
A simple way to implement this would be to register a function that would
be
called N seconds before the script would timeout.
register_timeout_handler(2, function() { die(PHP timed out.); });
It would be called just as a shutdown function - in fact I'd like to use
the
same function as my shutdown function and get the error with
error_get_last(). Of course set_time_limit(0) could be used in this
function
to prevent the timeout of the timeout handler. This does not prevent
timeout since set_time_limit could have been called by the script before
the
timeout anyway.
I like this. Although, I'd rather the first parameter were in milliseconds
instead of seconds. This would tell PHP 'x' milliseconds before script
termination to call the specified function. That function would then have
the remainder of the time slice to execute cleanup routines and send any
errors to the user. This approach also doesn't require a whole new
configuration option in php.ini.
On that note I also miss a function which returns the time the script can
keep running for. If that calculate needs to be calculated to implemented
to
implement this, why not make the value available to the PHP script?
This is already possible to do. I do this in WebCron by setting a variable
with the value of microtime() at the start of execution and figuring out how
long the script can actually run for. Then, I stop executing a task if
there are less than a few seconds left on the clock so that there is ample
time to clean up gracefully. For more information:
http://barebonescms.com/documentation/webcron/
Then I expose a convenience function called WC_GetTimeLeft() to modules and
tasks that can use it to test to see how much time is left on the clock to
execute the script. The approach works quite well. As an example, I use
WC_GetTimeLeft() extensively in my WebCron Site Backup module that can
backup websites of any size over HTTP/HTTPS.
http://barebonescms.com/documentation/webcron_site_backup/
So, while it can and has been done, it does require a little extra work at
the start of the script and obviously isn't as accurate as a dedicated
function in PHP itself would be.
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management system
for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
http://barebonescms.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Access Modifiers
Good Sugesstion. Currently I'm forced to use huge internal classes for my framework because dividing them into smaller classes would expose internal behavior to the outside... the application layer. This would solve that problem. ~Hannes On 3 March 2011 18:21, Jarrod Nettles jnett...@inccrra.org wrote: Has there been any discussion on access modifiers for classes? I looked through the existing RFCs and searched through old discussions on the mailing list but didn't come up with anything. Specifically, I think it would be beneficial (for framework developers in particular) if classes could be marked as public, private, etc. I haven't really thought through exact definitions on how each modifier would restrict but here is a use case. A developer is working on an object-oriented framework that uses namespaces and uses classes extensively. He considers many of the classes to be for internal use only, that is, they will only be used by the internal workings of the framework core, not by any web application that somebody builds using his framework. That being the case, the developer would like to restrict access to certain classes so that they can only be accessed in certain situations. Proposal (after five minutes of thought) 1. Public - A class can be instantiated or called statically from anywhere. For reasons of backward compatibility a class without any modifier would be considered public. 2. Internal - A class can only be instantiated/called from within the same root namespace. If I have a class Core\Mvc\View, only from within a class sharing the same root namespace (ex: Core\Html\Textbox) would I be able to access the View class. 3. Private - A class can only be instantiated/called from within the exact same namespace. Example, class Core\Mvc\View could only be accessed from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller). What do people think? I'm not too concerned with the exact three I listed above, but more and more I think it would be wise if there were a way to restrict the accessibility of classes between namespaces. Jarrod Nettles Application Developer - Technology INCCRRA p 309.829.5327 - f 309.828.1808 This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission. Please consider your environmental responsibility before printing this e-mail
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
No you can't gracefully handle all fatal errors. The shutdown function will
be called after *some* fatal errors but not all of them. See the bug I
reported here for more information: http://bugs.php.net/bug.php?id=54195
~Hannes
On 9 March 2011 16:12, Ferenc Kovacs i...@tyrael.hu wrote:
FYI you can gracefully handle every error. even the non-recoverable ones.
if you check my library you can test it also, I have an example file for
every non recoverable error (E_PARSE, E_CORE_ERROR, etc.).
from my point of view, every userland error should be catchable from
userland.
the max execution time servers two purpose:
- it saves you from shooting you in the leg (will abort an infinite loop
for example)
- it could be used as a tool by the sysadmin to restrict the cpu usage in a
shared hosting environment.
the ability to execute code via register_shutdown_function after the
Maximum execution time exceeded fatal error thrown by the engine makes the
second point void (except if you disable the register_shutdown_function,
which you would do of course in a shared environment).
so I think that it should be only used for the first problem, in which case
it could be catchable IMO, because it doesn't leave the engine in an
unstable state.
Tyrael
On Wed, Mar 9, 2011 at 3:53 PM, Hannes Landeholm landeh...@gmail.comwrote:
That's not a problem. Timeouts should be non-recoverable IMO as it's a
serious problem and I think most PHP developers would agree with this.
Making errors recoverable is difficult to implement, could have
performance penalties and be conceptually wrong when the state is defined as
never allowed to happen.
What I'm concerned about is that all problems should be able to be handled
gracefully from the register_shutdown_function like showing an informative
page, setting HTTP status, logging the problem, sending an error report,
etc. Not all fatal errors can be caught this way, including script timeout.
~Hannes
On 9 March 2011 15:39, Ferenc Kovacs i...@tyrael.hu wrote:
no, it only means that you cant return to the original scope and continue
the execution of your script.
as you can't throw exceptions also, because your code is running without
a stack frame.
you can check out the https://github.com/Tyrael/php-error-handler its a
little class which operates with register_shutdown_function to allow
handling non-recoverable errors before halting.
there are too many case in the php src where non-recoverable errors are
triggered for non fatal problems.
that should be changed, so open a bugreport if you think you found one,
where isn't neccessary to halt the execution.
Tyrael
On Wed, Mar 9, 2011 at 3:30 PM, Hannes Landeholm landeh...@gmail.comwrote:
You mean the shutdown function is called and 1 nanosecond later PHP
crashes
so you don't have time to do anything?
~Hannes
On 9 March 2011 15:27, David Muir davidkm...@gmail.com wrote:
Hmm, I think I worded that poorly.
A function registered with register_shutdown_function does execute
when
the max_execution_time is exceeded.
What it doesn't let you do is to recover in the same way an error
handler would let you.
David
On 09/03/11 22:56, Hannes Landeholm wrote:
I second making time limit reached catchable. All non catchable
fatal
errors
are a problem for me. I need to handle problems gracefully to ensure
the
stability of production systems instead of PHP just killing itself
without
warning. I just reported a similar issue:
http://bugs.php.net/bug.php?id=54195
A simple way to implement this would be to register a function that
would
be
called N seconds before the script would timeout.
register_timeout_handler(2, function() { die(PHP timed out.); });
It would be called just as a shutdown function - in fact I'd like to
use
the
same function as my shutdown function and get the error with
error_get_last(). Of course set_time_limit(0) could be used in this
function
to prevent the timeout of the timeout handler. This does not
prevent
timeout since set_time_limit could have been called by the script
before
the
timeout anyway.
On that note I also miss a function which returns the time the
script can
keep running for. If that calculate needs to be calculated to
implemented
to
implement this, why not make the value available to the PHP script?
~Hannes
On 9 March 2011 02:30, David Muir davidkm...@gmail.com wrote:
Although it doesn't let you recover from a timeout, you could use
register_shutdown_function to gracefully exit after a fatal error.
register_shutdown_function(function(){
$error = error_get_last();
if($error $error['type'] === E_ERROR){
echo 'PHAIL! Oh noes, something went wrong!';
// do whatever else you need to do before quitting
}
});
Cheers,
David
On 08/03/11 22:39, Pierre Joye wrote:
hi,
is not the goal
Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
Yes.. apparently it works. My mistake. I accidentally tested it in a context
with error suppression enabled.
Apparently there where some other reason for it not being gracefully caught
in production then. Going to have an extra look at it. Closing the bug in
the meantime.
~ Hannes
On 9 March 2011 17:01, Ferenc Kovacs i...@tyrael.hu wrote:
tyrael@devel-tyrael:~/c$ php -f fatal.php
PHP Fatal error: Call to a member function bar() on a non-object in
/home/tyrael/c/fatal.php on line 9
PHP Stack trace:
PHP 1. {main}() /home/tyrael/c/fatal.php:0
Houston we have a problem: Array
(
[type] = 1
[message] = Call to a member function bar() on a non-object
[file] = /home/tyrael/c/fatal.php
[line] = 9
)
as I mentioned, it works.
Tyrael
On Wed, Mar 9, 2011 at 4:59 PM, Hannes Landeholm landeh...@gmail.comwrote:
No you can't gracefully handle all fatal errors. The shutdown function
will be called after *some* fatal errors but not all of them. See the bug I
reported here for more information: http://bugs.php.net/bug.php?id=54195
~Hannes
On 9 March 2011 16:12, Ferenc Kovacs i...@tyrael.hu wrote:
FYI you can gracefully handle every error. even the non-recoverable ones.
if you check my library you can test it also, I have an example file for
every non recoverable error (E_PARSE, E_CORE_ERROR, etc.).
from my point of view, every userland error should be catchable from
userland.
the max execution time servers two purpose:
- it saves you from shooting you in the leg (will abort an infinite loop
for example)
- it could be used as a tool by the sysadmin to restrict the cpu usage in
a shared hosting environment.
the ability to execute code via register_shutdown_function after the
Maximum execution time exceeded fatal error thrown by the engine makes the
second point void (except if you disable the register_shutdown_function,
which you would do of course in a shared environment).
so I think that it should be only used for the first problem, in which
case it could be catchable IMO, because it doesn't leave the engine in an
unstable state.
Tyrael
On Wed, Mar 9, 2011 at 3:53 PM, Hannes Landeholm landeh...@gmail.comwrote:
That's not a problem. Timeouts should be non-recoverable IMO as it's a
serious problem and I think most PHP developers would agree with this.
Making errors recoverable is difficult to implement, could have
performance penalties and be conceptually wrong when the state is defined
as
never allowed to happen.
What I'm concerned about is that all problems should be able to be
handled gracefully from the register_shutdown_function like showing an
informative page, setting HTTP status, logging the problem, sending an
error
report, etc. Not all fatal errors can be caught this way, including script
timeout.
~Hannes
On 9 March 2011 15:39, Ferenc Kovacs i...@tyrael.hu wrote:
no, it only means that you cant return to the original scope and
continue the execution of your script.
as you can't throw exceptions also, because your code is running
without a stack frame.
you can check out the https://github.com/Tyrael/php-error-handler its
a little class which operates with register_shutdown_function to allow
handling non-recoverable errors before halting.
there are too many case in the php src where non-recoverable errors are
triggered for non fatal problems.
that should be changed, so open a bugreport if you think you found one,
where isn't neccessary to halt the execution.
Tyrael
On Wed, Mar 9, 2011 at 3:30 PM, Hannes Landeholm
landeh...@gmail.comwrote:
You mean the shutdown function is called and 1 nanosecond later PHP
crashes
so you don't have time to do anything?
~Hannes
On 9 March 2011 15:27, David Muir davidkm...@gmail.com wrote:
Hmm, I think I worded that poorly.
A function registered with register_shutdown_function does execute
when
the max_execution_time is exceeded.
What it doesn't let you do is to recover in the same way an error
handler would let you.
David
On 09/03/11 22:56, Hannes Landeholm wrote:
I second making time limit reached catchable. All non catchable
fatal
errors
are a problem for me. I need to handle problems gracefully to
ensure the
stability of production systems instead of PHP just killing itself
without
warning. I just reported a similar issue:
http://bugs.php.net/bug.php?id=54195
A simple way to implement this would be to register a function
that would
be
called N seconds before the script would timeout.
register_timeout_handler(2, function() { die(PHP timed out.);
});
It would be called just as a shutdown function - in fact I'd like
to use
the
same function as my shutdown function and get the error with
error_get_last(). Of course set_time_limit(0) could be used in
this
function
to prevent the timeout of the timeout handler. This does not
prevent
timeout since set_time_limit could have been called
Re: [PHP-DEV] Re: Clarification on the Enum language structure
Lemme jump in here... An enum declaration is just a list of unique PHP
constants.. not mathematical sets. You could argue the same thing for
constants (that they can only contain scalars and not any values -
therefore not useful). If developers need to model the period table they'd
define the data necessary for it in an array or put it in a database (and
possibly use an enumeration as keys to access the data). The simplicity of
enumerations is exactly the point and what makes them useful. For stuff more
advanced than enumerations there are arrays, classes. The values of
enumerations should contain very little information. This is because the
values are used as keys and placeholders to identify some other behavior or
data. Put the actual data that the enumeration values represent/identify IN
the values is wrong IMO.
Hannes
On 23 February 2011 15:22, Martin Scotta martinsco...@gmail.com wrote:
Think on any finite set of elements that cannot be represented with
integers
because they don't hold enough data... or because the repeated values.
An extremely example could be the Periodic Table, finite set of elements,
where each element holds a lot of information.
function print_element(Element $e) {
echo $e-weight(), PHP_EOL,
$e-density(), PHP_EOL,
$e-protons(), PHP_EOL,
$e-neutrons();
}
print_element(Element:Hydrogen);
print_element(Element:Argon);
print_element(Element:Iron);
How do you implement this with just string=integer define or constants?
so you need classes.. do they fit well? I don't think so
$h = new Hydrogen(); // What would mean this?
$h = Element::Hydrogen(); // probably with a static method
$h = Element::Hydrogen; // class constant? lack of objects support
Martin Scotta
On Wed, Feb 23, 2011 at 10:49 AM, Alexey Zakhlestin indey...@gmail.com
wrote:
On Wed, Feb 23, 2011 at 4:35 PM, Martin Scotta martinsco...@gmail.com
wrote:
Martin Scotta
On Wed, Feb 23, 2011 at 7:12 AM, Ben Schmidt
mail_ben_schm...@yahoo.com.auwrote:
Are you suggesting this as an enum member function, or just a regular
function in any old class?
Enum member funcion? How much it should be like a class before you
call it a class?
Exactly. It's crazy. If you want a 'member function' use a class, not
an
enum.
why not supporting methods for enum values?
developers will need that, and by providing type hinting, they will
just
create the logic somewhere else...
why would developers need this? can you elaborate with some real-life
scenario?
I thought enums are just strong-typed constants
--
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/
Re: [PHP-DEV] Re: Clarification on the Enum language structure
Let me jump in here and say that I agree that strings are useful. IMO
any scalar type should be allowed for enum's. String enum's are great
for understanding debug data. Also it would integrate smoothly with
MySQL enums (building queries) and when you want to model enumerations
in an external API or framework. When you say enums should be
integers you assume that the programmer has the final decision on the
values. But if you want to enumerate possible string return codes from
an external API you'd be forced to write a translation function that
translate the values you read to the internal enumeration
representation.
For example, say that http://www.example.org/api can return either
fail, success or timeout, you'd like to put these in an
enumeration so they make sense instead of having magic values
scattered across the code.
enum ExampleReturnCodes {
FAILURE = fail;
SUCCESS = success;
TIMEOUT = timeout;
}
if ($ret == ExampleReturnCodes::FAILURE)
echo noes;
This also highlights why it would be nice to name enumerations just
like classes. They provide a handle for the constants within so they
can be used for reflection. See, I'd like to do something like:
if ($ret enumof ExampleReturnCodes)
\trigger_error(Unknown enumeration value returned!, \E_USER_ERROR);
and:
print(Got: . ExampleReturnCodes::getName($ret)); // PrintsGot: FAILURE
I'm suggesting this as an additional behavior. Declaring enumerations
without names should make the contents be declared just as normal
namespace/class constants. In addition, declaring a named enumeration
enum_name in a class could give the enumeration the name either
enum_name (if it wouldn't be confusing and the named collision risk
is acceptable), class_name::enum_name (if the :: operator could be
programmed to also resolved enumeration types and not only class
constants), class_name_enum_name (if it would be acceptable to
automatically merge the class name with the enumeration name) (and
possibly other solutions). Another solution is to forbid class
enumerations from being named and only use them as a constant grouping
syntax.
My 5 cents.
Hannes
On 18 February 2011 15:44, Arvids Godjuks arvids.godj...@gmail.com wrote:
Hello!
I should comment on why people want strings as enum values - just look
at ENUM type in MySQL. People use it, and if you take a look from that
perspective - it makes sense.
But we are not a MySQL only world, so it does not make sense to do
strings, because in other databases usually 1 byte integers are used
for that.
P.S. But I really like MySQL ENUM, it's really helpfull to see some
meaningfull representation instead of plain numbers. And MySQL is able
to convert enum to real integer like it is stored internaly: SELECT
enum + 0 AS enum FROM table. Will get you the numbers, not the string
representations. So it's really no brainer to make enumerations to
work transparently with MySQL.
2011/2/18 Jarrod Nettles jnett...@inccrra.org:
I did some research on methods in enums and discovered that there is some
usefulness to the idea - I wouldn't go so far as to say that they would be
needed, but C#, for example, allows you to create extension methods for
enums and MSDN has a decent real-world example of its use.
http://msdn.microsoft.com/en-us/library/bb383974.aspx
I still don't understand why we would need string values (or any other
non-integral type) but like you said Ben - if you need something like that
you're not using the right datatype. Build a class. Here's my reasoning for
enum values.
enum Wood{
OAK,
ASH,
WILLOW,
GOPHER
}
There's nothing in there that would necessitate needing a string value and
really, if you need a string value, pass in a string as your parameter!
Enumerations should be used to represent a set of data where the value
itself isn't so important, it’s the consistency of the value that's
important. It’s the fact that I've chosen gopher wood and I know that even
though Wood::GOPHER really means 3, I don't have to remember what 3
represents because I can specifically type that I want gopher.
-Original Message-
From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au]
Sent: Thursday, February 17, 2011 4:52 PM
To: Martin Scotta
Cc: Jarrod Nettles; Thomas Gutbier; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure
Also, I feel like it should be restricted to integral types only, and
defaults to a zero-based incrementing integer. This is more in line with
other programming languages that already implement enums and will present
expected behavior for people moving over to PHP.
for me that's a plain old interpretation of constants.
constant values were only integer values because of their implementation,
nowadays they could be anything you want, int, float, string and even
objects.
I partially agree with that.
I'm going to be a bit extreme here, but here's a thought:
An
Re: [PHP-DEV] [RFC] Var_export tabbing
If you're looking into doing something that are both useful and good for learning C, my suggestion is to hack PHP in some way that makes something possible (in PHP) that you couldn't simply accomplish by writing a simple wrapper function or workaround. Making var_export use tabs instead of spaces is easily accomplished by wrapping it in another function that preg_replaces starting line spaces with tabs. Reading your suggestion, I almost get the feeling that you believe the only reason var_dump doesn't have more arguments (or does this yet) is because nobody thought about it or had time changing it. Changing built in php functions is not A Good Thing™ in general. Functions should serve a specific purpose, not have a gazillion arbitrary arguments for every possible use case. For just the purpose of just learning C however, go ahead. Sounds like a good start. Hannes On 24 January 2011 19:26, Michael Morris dmgx.mich...@gmail.com wrote: I've been trying to think of something that would be a good project to cut my teeth on for a first C project in forever and I'd rather work on something that might be useful. While cleaning tabbing on a var_export for a test class I think I have an idea. What I'm looking for is two things. One, is this the sort of thing that a beginner to C (not a beginning programmer mind you - I've been doing PHP scripting for, gosh, 7 years now) can do. If so I'll do this just for the experience of it because I need to learn how to prep patches and the remainder of the process for more major patches - such as the include style I RFC'ed earlier. It looks like if it's going to happen I'll have to learn how to do it. Anyway, var_export takes 2 arguments - the expression to be converted and whether to return or echo it. I'd like to add a third, whether to use spaces (default) or tabs for indentation For backwards compatibility null would mean uses spaces, and use 2 per indentation. If set to true a tab character would be used. Thoughts and input appreciated.
Re: [PHP-DEV] How deep is copy on write?
Using references does not speed up PHP. It does that already
internally, if I'm not mistaken. The point of my post was that
assigning values to tree arrays are in general faster than a full
array copy.
Hannes
On 19 January 2011 08:36, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote:
Yep. PHP does clock up memory very quickly for big arrays, objects with lots
of members and/or lots of small objects with large overheads. There are a
LOT of zvals and zobjects and things around the place, and their overhead
isn't all that small.
Of course, if you go to the trouble to construct arrays using references,
you can avoid some of that, because a copy-on-write will just copy the
reference. It does mean you're passing references, though.
$bar['baz'] = 1;
$poink['narf'] = 1;
$a['foo']['bar'] = $bar;
$a['foo']['poink'] = $poink;
Then if you test($a), $bar and $poink will be changed, since they are
'passed by reference'--no copying needs to be done. It's almost as if $b
were passed by reference, but setting $b['blip'] wouldn't show up in $a,
because $a itself would be copied in that case, including the references,
which would continue to refer to $bar and $poink. So a much quicker copy,
but obviously not the same level of isolation that you might expect or
desire. Unless you did some jiggerypokery like $b_bar=$b['bar'];
$b['bar']=$b_bar; which would break the reference and make a copy of just
that part of the array. But this is a pretty nasty caller-callee
co-operative kind of thing. Just a thought to throw into the mix, though.
Disclaimer: I'm somewhat out of my depth here. But I'm sure someone will
jump on me if I'm wrong.
Ben.
On 19/01/11 6:09 PM, Larry Garfield wrote:
That's what I was afraid of. So it does copy the entire array. Crap. :-)
Am I correct that each level in the array represents its own ZVal, with
the
additional memory overhead a ZVal has (however many bytes that is)?
That is, the array below would have $a, foo, bar, baz, bob, narf, poink,
poink/narf = 8 ZVals? (That seems logical to me because each its its own
variable that just happens to be an array, but I want to be sure.)
--Larry Garfield
On Wednesday, January 19, 2011 1:01:44 am Ben Schmidt wrote:
It does the whole of $b. It has to, because when you change 'baz', a
reference in 'bar' needs to change to point to the newly copied 'baz', so
'bar' is written...and likewise 'foo' is written.
Ben.
On 19/01/11 5:45 PM, Larry Garfield wrote:
Hi folks. I have a question about the PHP runtime that I hope is
appropriate for this list. (If not, please thwap me gently; I bruise
easily.)
I know PHP does copy-on-write. However, how deeply does it copy when
dealing with nested arrays?
This is probably easiest to explain with an example...
$a['foo']['bar']['baz'] = 1;
$a['foo']['bar']['bob'] = 1;
$a['foo']['bar']['narf'] = 1;
$a['foo']['poink']['narf'] = 1;
function test($b) {
// Assume each of the following lines in isolation...
// Does this copy just the one variable baz, or the full array?
$b['foo']['bar']['baz'] = 2;
// Does this copy $b, or just $b['foo']['poink']?
$b['foo']['poink']['stuff'] = 3;
return $b;
}
// I know this is wasteful; I'm trying to figure out just how wasteful.
$a = test($a);
test() in this case should take $b by reference, but I'm trying to
determine how much of a difference it is. (In practice my use case has
a vastly larger array, so any inefficiencies are multiplied.)
--Larry Garfield
--
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
[PHP-DEV] Persistent, file backed, mmap APC hack
Hi, I use a multithreaded MPM of apache called peruser where we're hosting a bunch of sites, each with their own virtual host. Each virtual host needs to be isolated so I'm using chroot and other stuff to keep them apart. APC was a must as getting good throughput was important. However, APC would make all sites share memory containing cached PHP files and user data. A major security breach. So I was looking at the source code of APC and saw that it was using mmap() to map shared memory. If mmap used a filed backed shared memory instead you could a) get a persistent cache so the child processes could be terminated without dropping it and b) inherit the file system permissions c) make chroot define where the cache would be, essentially giving every virtual host their own APC cache. You could also use shm_get(), however IPC was not enabled on my kernel. I then proceeded to write a hack/proof of concept to APC 1.3.7 which accomplished this. This is a breakdown of the differences between vanilla APC and my hack: - Vanilla APC will allocate all shared memory when Apache starts (before chroot etc) + Hacked APC will delay shared memory initialization upon the first request of the child thread (after chroot etc) + Hacked APC will reserve a memory region when Apache starts so there will be no difference in address location. + Hacked APC only supports exactly one memory segment. + Hacked APC must be built with --enable-mmap + Hacked APC is recommended to be built with --enable-apc-pthreadrwlocks + Hacked APC adds a line Hacks: Hacked for shared MMAP support to phpinfo() to indicate that it has been loaded. - Vanilla APC just uses mmap() as a way to allocate shared memory + Hacked APC utilizes the file backed up feature of mmap, you must set apc_mmap_file_mask to a place to store the APC cache/swap, and this file will have the exact size of apc.shm_size. - Vanilla APC allocates shared memory once, it never loads previously memory. + Hacked APC will always load existing memory from the cache. Every time you start Apache the start time is recorded. If the start time differs, the cache will be zeroed, otherwise the cache will be loaded and the already initialized cache structures in it be used. Note: This could lead to a race-like condition if two PHP instances use the same cache and where started at different times. - Vanilla APC uses apc_mmap_file_mask as a temporary file and requires XX as a placeholder for unique hash. + Hacked APC uses apc_mmap_file_mask as an exact file name and requires it to be specified. - Vanilla APC has no Environment separation. The cache is initialized once and shared between all apache childs. + Hacked APC will load the cache from file specified by apc_mmap_file_mask. In addition, it will create it if it doesn't exist with the permissions 0600 and with the uid/gid of the the child process. The path is also affected by chroot. This is a double layer of security. I'm using this to get different APC caches per virtual host and limit memory. However it should also, theoretically, be possible to use it to enable a shared cache for PHP instances running with fast cgi. This could save a lot of memory. However you would then have to make some changes. For example, the memory is currently pre-mapped when apache is started so all children will share the same addresses. One way to solve this would be to implement the cache so no direct memory addresses are used, only offsets. Also, the hack currently stores the PHP start time and reinitializes the cache file when apache is restarted, and if you're removing the reinitialization you would then have a persistent data storage. A really crazy idea would then be to use APC as a persistent database instead of mySQL. Just gotta make sure APC is ACID compliant first! ;) Some notes on performance: I load tested this with a wordpress site and I did not detect any reduction in performance. I got 2x the throughput with both vanilla and hacked APC. This could however be slower in some cases. For example, this uses disk access to read and store the cache. However it maps the file in shared mode, so no disk reading should actually take place if it's already open. And simply reading/writing the memory does not guarantee that the changes are written to disk until the memory is actually unmapped. I should also not have to mention that this is an experimental hack. If you use this for anything important you're insane. The patch: http://pastebin.com/4GS83nKs Regards, Hannes Landeholm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Experiments with a threading library for Zend: spawning a new executor
Hello, I don't think a language becomes a beginners language just because many new programmers use it. And it's still not a good argument for not including new features. As long as the new thread doesn't share any memory/variables with the spawning context, no reasoning is required at all. It's when you start sharing objects that things get complex. Just a simple threading implementation with a strictly defined way to IPC would be very helpful. It's not super useful in web application programming as handling web requests is already packaged into small units of work.. web requests. So in that sense a web application is already multi threaded. However it's interesting for CGI scripts. The other week I wrote a PHP CGI proxy for example. Because PHP didn't have threading, I had to bother with select polling. Hannes On 18 January 2011 23:10, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Sorry, but that's my topic, and the most well know interpreters that 'pulled off' threading with shared data are for Java. The interpreter Given to what complications Java programmers should go to make their threaded code work, I have a lot of doubt that 95% of PHP users would be able to write correct threaded programs. Reasoning about threaded programs is very hard, and IMHO putting it into the beginners language would be a mistake. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
