> 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.
Using weak references is the only way to design non caching references and the only way to correctly implement the observer pattern without leaking memory as outlined in the RFC. I need this feature and 12 others also do who voted on bug #52318. For everyone that votes on a ticket there's probably a hundred others who also needed it but didn't find the ticket, didn't bother creating an account or didn't bother voting. When it's hard to contribute people won't bother. I'm trying to speak for the users that have too little time to argue in mailing lists or write RFC's or learn C or jump trough endless hoops in a process designed so that the core development team can ignore the community more democratically. The users that just suck it up and design their applications or frameworks poorly instead because they don't have time. I can also tell some of my own experience as an additional use case. Since this feature did not exist I was forced to implement caching referencing in my framework which resulted in huge memory problems during certain object intensive procedures. An application I developed for a customer crashed when it bumped into 330 MB of memory. I had to resort to unsetting stuff manually - basically making hacks which did memory management - which is not something you're suppose to be required to do in a memory managed language like PHP. I anticipated this problem when designing my framework but could not do anything about it since PHP did not provide me with the necessary tools to actually solve it. As Ethan Nicolas puts it in the last sentence of this paragraph: ""This might look okay on the surface, but the strong reference to widget will almost certainly cause problems. We have to know (with 100% certainty) when a particular Widget's serial number is no longer needed, so we can remove its entry from the map. Otherwise we're going to have a memory leak (if we don't remove Widgets when we should) or we're going to inexplicably find ourselves missing serial numbers (if we remove Widgets that we're still using). If these problems sound familiar, they should: they are exactly the problems that users of non-garbage-collected languages face when trying to manage memory, and we're not supposed to have to worry about this in a more civilized language like Java."" Just as "classes is not needed when you have arrays with functions in them", is week references is not needed "when you can implement ugly memory management unset hacks". A language should provide the tools a programmer need to design their applications well. Currently I am unable to design my applications well because PHP does not support designing my ID-to-object-referencing-component well because PHP does not support weak references. Tell me how I should design an application so that you can get an "already initialized object" for a certain ID while enabling the GC to collect it without using weak referencing. Then I'll be convinced that the feature "is not 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 (framework&co) and come back once you have reached more > maturity with both the design and the implementation of this feature. I'm not sure how to respond to that. "The more I look at it" does not parse as an actual argument of anything in my head. Be more specific. I strongly disagree that Weak References should be buried in a PECL extension. I speak for a lot of PHP developers when I say that I don't want to have anything to do with PECL. I'm a programmer - I don't want to spend valuable time compiling and configuring anything. Compiling is a nightmare for most PHP developers - especially on Windows. A developer is a user - if it's not simple to develop he will move to other frameworks or languages. PECL is great for experimental, complex stuff like APC or very specific types of integration and purposes. Not specific language features - they should be implemented in the language. Nobody likes writing platform-dependent code. Also I'm not sure what you expect when you say that it "reached more maturity". To what end? A feature doesn't really get much more well defined and simple than this. It's like the whole "it's a single class with two functions" and "it's implemented as a fundamental component in other major OO languages" counts for nothing. Like all other languages perhaps accidentally implemented it without actually needing it and now we need to discuss the feature again endlessly and "gather community feedback" for years even though all the research has already been done. It will be simple to extend the class with additional methods if other use cases should emerge. > Don't be afraid to miss 5.4 either, next one comes next year :) I've been a PHP fan for years and endured the patchy OO 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 (framework&co) 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
