[news.eclipse.technology] Re: Decision making process in Eclipse project

[Alvin Thompson <nobody@xxxxxxxxxxx>]

 > An idea is an idea, regardless of where it comes from. Given some of 
the code
> quality in SWT, I would think they need every bit of help they can get.

are we now discussing code quality or are we discussing your issues with 
the decision-making process?

> This page is still merely a description of SWT as a component of Eclipse whereas
> it has become a technology in its own right.

i agree on this. a more 'independent' home page (in addition to the 
current one) is warranted.

> First of all, anonymous classes are extremely bad practice.

anonymous classes are extremely bad practice? i use them extensively in 
event code and i like to think of myself as a reasonably accomplished 
programmer. please convince me of this.

besides, your original assertion was that there would be no other 
changes needed in the eclipse code. now it seems using your code would 
require rewriting all event code to not use anonymous nested classes, as 
well as ensuring that no future submissions use them. that's a lot of 
work for everyone else just because you don't like that particular 
programming style.

> Second of all, creating a new object and dumping it into nowhere is a bad idea
> as well.

i don't understand this statement. please explain it.

> Third of all, if this was held in a strong reference, there would be no way to
> unhook the event. This can lead to extremely HUGE memory leaks... consider ...
>
> eventTable.hook(
>      SWT.SOME_EVENT, new EventListener() {
>           Dialog dlg;
>           public void handleEvent(Event e) {
>
>              dlg = new Dialog(shell, STYLE);
>              // add 12 composites with multiple widgets ad attached to data
> objects.
>              // Link the widgets into data objects using jface
>              // show the dialog.
>          }
>       }
>  );
>
> In this case, event listener will hold onto the dialog and all of its controls
> and so on forever and there is absolutely no way to unhook it and make the
> references go away.

true, the code above will hold on to the most recent dialog object and 
its members indefinitely. until it is called again, BUT:

first, it is poorly written NOT because it hangs on to the Dialog object 
(it should), but rather because it creates a new Dialog object every 
time it is called instead of reusing the old one.  the first rule of 
event management code is to never--ever--create objects unless you 
absolutely have to; if you must use an object, hold on to it for reuse.

second, i have looked at a lot of code and i have never seen anyone 
write an anonymous nested class that used its own members to hold 
disposable objects. what would be the point? while it is permissible to 
use contrived examples to prove a point, this one is so unlikely as to 
be unreasonable to expend effort accounting for.

third, if this (or any) framework were to try to account for every 
possible user's bad programming practice, it would be very large and 
very slow (well, larger and slower :) .

fourth, this code could be easily written without the anonymous inner 
class and it would exhibit the same behavior.

> If you absolutely insist on using anonymous classes, you should store their
> instances so that on dispose the window can unhook them. The more circular
> strong references you have in code, the more potential for huge memory leaks.
>
> To summarize:
>
> 1) Anonmyous classes are bad but if you insist on using them, store their
> instances in class variables.
> 2) Memory leaks are caused by circular strong references.

does creating new objects during event dispatch have the potential for 
memory leaks? of course. but that has nothing to do it being in an 
anonymous inner class.

where are the circular references here? i don't see any. but i DO know 
that the garbage collector is smart enough to reclaim unused circular 
references (that's java 101). i also know that WeakHashMap IS NOT smart 
enough to know that a strong reference to an object is circular (that's 
java 102).

> Everyone? From what I can tell individuals are making the vetos. There is no
> voting process that I can see so the word "everyone" is rather a misnomer.

on the bottom of every bug report/RFE page there is the link 'vote for 
this bug'. if people think it is a good idea, they will vote for it.

> People loose interest because they submit ideas and are relied to with hostility
> or ignored.

i have not observed anyone being especially hostile to you. on the other 
hand, you seem to be exceptionally combative in this newsgroup. you 
cannot expect people to be cooperative when you take this tone. please 
don't give me any 'he started it' arguments as i would find it hard to 
believe.

> I dont expect "favored" treatment. I expect people to act like professionals and
> people who are more concerned about doing things right. Developers that treat
> code as if it was their baby and anyone suggesting changes is murdering their
> baby need to get a reality check.

it is hard to expect others to act like a professional when you yourself 
do not. you started your last post impugning the code quality in SWT. 
how is this constructive? in a way, the code IS their baby; they have 
put a lot of time and effort into it. if you were a parent and someone 
told you that your baby was ugly, you would take offense as well. you 
claim your code is better, but the SWT team has produced an actual 
working product whereas you have not, a product that you yourself admit 
that many people wish to use.

> ... Im not
> in open source to play politics, Im in it to write good code.

you are obviously young if you make this statement, so i will give you a 
very good piece of advice: everything in life involves playing politics 
to some degree. if you do not make an effort to 'play well' with others 
you entire life will be much more difficult. this problem you are having 
with the SWT developers is just one example. are there others?


sincerely,
alvin