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 requirement- by me. So if a language feature allows a programmer to write more messier code the language should not provide those features? I disagree with that. > In PHP, I believe a web or cli app that uses enough resources to bomb > memory limits on a server, needs to be re-factored. I have definitely > written multi-process PHP daemons that go to disk or over the network > for taxing operations that need cached and had very little trouble > with rudimentary memory management patterns, so from my perspective I > can't really see why given the toolset PHP provides that this is such > a problem. It's not a mathematical problem. Yes you can still design your code so that it breaks responsibilities and decoupling. You can write special unset functions and document that they need to be called whenever objects are "not used anymore". If you're mainly a C programmer I also understand your indifference to having the userland developer worry about memory management. However, I think PHP should be a civilized language that takes care of stuff like that. > This is just my opinion, I don't have a strong opposition to this > feature, anything "new" to PHP I usually get excited about, I simply > wanted to give a few counter arguments as the fact that this feature > is being presented as a dire and long over due missing feature to the > language is a bit dramatic. Not saying its useless and doesn't belong > in PHP or I would never want it to exists, I just would hate to see > something rushed through that didn't get a bit of testing and typical > QA from a language that affects millions of people. I had a two week discussion period that was mostly silent and I felt the consensus was generally in favor of the feature which is why I started the vote. It's a single class with two functions. It implements a widely researched and adopted design pattern. It's not a new or experimental concept. It will get "a bit of testing" and it has been given opportunity of "typical QA" like other features voted for an accepted into 5.4. ~Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
