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

Reply via email to