> Sorry to hear you took that way... I still think a pub is a good option. > > "We" are somewhere between the stone ages and craftsmen, and it > frustrates me immensely... > > Ok, I promise I'll keep it to myself from now on... ;-) >
I don't necessarily disagree, I just don't think this (an Apache project) is the forum for raising those concerns ... it devalues the efforts of all open source committers, regardless of their level of competency. I'll join you in the pub. :) > Well, it is possible to intercept the garbage collector and warn the > developer of the event, if that is a concern. My understanding is that the garbage collector is something to be aware of, but not to be tinkered with (and could change subtly between each implementation of the VM). Thus any assumption, interaction with, or defensive programming because of the gc is bad practice. > In a way, I agree. The difference between using more soft references > vs life cycle management, is that the latter leads IMO to "accepted" > memory leaks and poor shutdown handling and the former leads to > 'non-function' which gets attended to more promptly. I disagree. During testing you might not even see the weak reference being collected and assume that the functionality is correct. Debugging a deployed application that uses weak references incorrectly like this is extremely difficult. Bottom line is that handling listeners is not the place for weak references. Weak references should be used in situations where you really don't care if the object in question disappears because, for example, you are able to re-load the data and re-create the object on demand. A typical scenario for weak references is a caching system. However, a listener is not that. Listeners add functionality for a reason and allow functionality to be added and removed dynamically. If you no longer want the functionality you added any more, you should remove it, not depend on a weak reference system (which may not even work) cleaning it up for you. It really isn't that difficult a concept to understand. Regards, Chris 2009/10/28 Niclas Hedhman <[email protected]>: > On Wed, Oct 28, 2009 at 5:48 PM, Christopher Brind <[email protected]> > wrote: > >> I don't find your response conducive to a happy, open and learning >> atmosphere. If you have a suggestion, please make it, but colourful, >> sarcastic language is not appreciated. > > Sorry to hear you took that way... I still think a pub is a good option. > >> With regards to listeners - in a UI application a good portion of the >> listeners added to objects are are going to be added for the duration >> of the application's life. > > To that I oppose, on the basis that things get 'muddier' over time, > and what originally was a 'near view' component over time has a > tendency to be buried deep inside layers of 'things', and > "application's life" is not necessarily the same application anymore. > >> public void somethingHappened(Event event) { >> >> // ... >> >> event.source.removeListener(this); >> } > > Fair enough... > > >> From other UI SDKs: >> >> - Android (which I've been using extensively recently) 'setListener' >> instead of 'addListener' which at first I thought I would find >> restrictive, but is actually quite liberating. > > I also think setListener() is a better form, where as if one needs > multiple ones, there is room to do so... > >> - Flex uses a functional programming approach for event handlers, one >> of the arguments when setting an event handler function being whether >> or not to use weak references for that handler. > > Uhh?? Functional programming doesn't allow side-effects like setting > permanent members of "something". What is missing here? > >> My general view of >> weak references is that they are not to be used lightly - it is very >> hard to create deterministic application behaviour if you have things >> being randomly garbage collected. At least a memory leak will be >> generally repeatable. > > Well, it is possible to intercept the garbage collector and warn the > developer of the event, if that is a concern. > >> If anything weak references, when used incorrectly like you seem to be >> proposing, encourage developers to be lazy and not care about proper >> lifecycle management. Would be much better for the whole >> community/industry to educate developers that even with Java you have >> to clean up after yourselves sometimes. > > In a way, I agree. The difference between using more soft references > vs life cycle management, is that the latter leads IMO to "accepted" > memory leaks and poor shutdown handling and the former leads to > 'non-function' which gets attended to more promptly. You may argue > that garbage collection doesn't occur often enough for development and > QA activities. > > > As for my sarcasm, I indeed think that our "trade" is in an abysmal > state due to "flexibility" in just about everything, languages, > frameworks, libraries, and what not... In a profession where success > is measured by "not total failure" and where we accept "bugs are > expected", "evolution is necessary" and "software needs restarts", we > are such a long way from being able to be proud of what we do. I am > NOT proud, I have added my fair share of bad code to the world, but at > least I am conscious about it, like you are, like many/most developers > at Apache are, but not the bulk of developers around the world, those > that "do their job" from 9-to-5. And I don't think it is "our" fault > per se. "We" have failed to create an eco-system that works, "we" > consider all ourselves "equals" not making much distinction between > our roles in such environment. The soldier is making his own bullets, > the factory worker makes his own nuts and bolts... if you see what I > mean. "We" are somewhere between the stone ages and craftsmen, and it > frustrates me immensely... > > Ok, I promise I'll keep it to myself from now on... ;-) > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug >
