Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #3733 > unrolled thread

Re: Weird window close be

Back to article view | Back to comp.lang.java.gui

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Weird window close be "Lew" <lew@THRWHITE.remove-dii-this> - 2011-04-27 15:46 +0000
    Re: Weird window close be "RedGrittyBrick" <redgrittybrick@THRWHITE.remove-dii-this> - 2011-04-27 15:46 +0000
      Re: Weird window close be "Lew" <lew@THRWHITE.remove-dii-this> - 2011-04-27 15:46 +0000

#3733 — Re: Weird window close be

  To: comp.lang.java.gui
Knute Johnson wrote:
> This is the part that I am curious about.  What makes it better practice 
> to 'build' the GUI someplace other than the constructor?

For that I recommend further reading.  I was doing it as an exercise to follow 
the advice I've read all over the place, is all.

> And to take that a step further, if you are building a GUI in a frame, why would it 
> not be even better to build it totally in the main() method and avoid 
> distributing the code out to the run()?

What's to avoid?  The run() seems to me to be the natural place to do that, 
given that SwingUtilities.invokeLater() wants a Runnable, and we want to do 
the build of the GUI on the EDT.

>> It was to show how one can translate that lip-service principle into 
>> practice that I presented the example.
> 
> Honestly, I'm just curious and want to understand the thinking behind 
> your method.  Are these best practices written down somewhere?

The thinking is that I should see how to follow the advice of these pundits, 
which indeed is written down in many places, none of which I can quote off the 
top of my hand.  The thinking is that I keep reading how dangerous it is to 
use partially constructed objects, how there can be uninitialized variables or 
thread dangers, how state of even final variables can appear to change, and 
how one should be in the habit of limiting constructors to construction. 
Apparently this is a new concept for you, but I must have seen it in a dozen 
places.

So what the heck, if this is such a good idea, let's see how hard it is to 
implement.  After all, if it's difficult, maybe one should consider not 
following this advice.  Turns out, it's not only easy but makes for quite 
clean and elegant code.  Thus the cost is nil, and the benefits, well, you 
just have to believe the pundits.  I don't have enough authority.

Sorry I don't have the links, but you can google them as easily as I.  If you 
go even further, as in Joshua Bloch's /Effective Java/, Item 1, you won't use 
constructors at all but static factory methods.

-- 
Lew

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]

#3736

  To: comp.lang.java.gui
Lew wrote:
> Knute Johnson wrote:
>> This is the part that I am curious about.  What makes it better 
>> practice to 'build' the GUI someplace other than the constructor?

I must admit I find it very natural to "construct" the GUI elements in a 
GUI object's constructor. For example: to instantiate JTextFields in the 
constructor of a subclass of JPanel.

>>
>> Honestly, I'm just curious and want to understand the thinking behind 
>> your method.  Are these best practices written down somewhere?
> 
> The thinking is that I should see how to follow the advice of these 
> pundits, which indeed is written down in many places, none of which I 
> can quote off the top of my hand.  The thinking is that I keep reading 
> how dangerous it is to use partially constructed objects, how there can 
> be uninitialized variables or thread dangers, how state of even final 
> variables can appear to change, and how one should be in the habit of 
> limiting constructors to construction. Apparently this is a new concept 
> for you, but I must have seen it in a dozen places.
> 

Doesn't the issue with partially constructed objects only arise if your 
constructor passes a reference to itself to other methods?

E.g. http://nat.truemesh.com/archives/000222.html

Or

    class ExamplePanel extends JPanel {
         ExamplePanel() {
             setLayout(new BoxLayout(this, BoxLayout.PAGE_AXIS));
             //                      ^^^^ partially constructed!
             add(new JLabel("One"));
             add(new JLabel("Two"));
             add(new JLabel("Three"));
         }
     }

Since the ancestral JComponent() constructor will have been completed 
before BoxLayout() gets to make use of it - isn't it a fully constructed 
JComponent so far as BoxLayout is concerned?

-- 
RGB

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#3737

  To: comp.lang.java.gui
RedGrittyBrick wrote:
> Doesn't the issue with partially constructed objects only arise if your 
> constructor passes a reference to itself to other methods?
> 
...
> Since the ancestral JComponent() constructor will have been completed 
> before BoxLayout() gets to make use of it - isn't it a fully constructed 
> JComponent so far as BoxLayout is concerned?

The questions you and Knute ask are valid and valuable.

I agree that there aren't dangers visible in the idiom of assembly in the 
constructor in the cases we usually see, where the constructing object sort of 
goes away after starting things off.

If I express a preference in the simple case it is that the notion of a run() 
on an argument to invokeLater() seems more "natural" than to run things from a 
constructor.  Indeed the recast does eliminate the need for an extra anonymous 
Runnable, making for cleaner code.

This I had not predicted, thinking /a priori/ that forcing code out of the 
constructor would increase complexity.  Instead, it simplified.

The second difference is one of planning.  Since the class is not written to 
prevent extension, it risks having subclasses.  Safety in the visible 
constructor might not convey to the inheritors.

Another danger is one of habit.  If one gets used to putting a lot of action 
in the constructor, one could trip on a corner case before realizing it.  If 
one habitually only lets fully-constructed objects participate, then safety is 
built in from the get-go.

Finally, it comes down to judgment and style.  When one knows that it is 
harmless, then of course there's no harm done.

Before reaching a decision on the style questions,

- should I rigorously push non-construction out of the constructor?
- how rigorously?

I wanted to explore how one could even do such a thing.  GUI assembly, so 
often and publicly done in constructors, seemed like a perfect candidate for 
the exploration.

I conclude that the rule to limit constructors to (object) construction is 
valuable, and can lead to lean code that expresses its algorithms as "literate 
code" quite naturally through method names and such.  It simplifies reasoning 
about thread boundaries in the cited example, and whether GUI assembly 
correctly resides on the EDT.  I found no disadvantages to the rule.  So far.

YMMV.

The group has responded intelligently with excellent and probing questions 
about the topic.  Your participation has immeasurably increased the value of 
the investigation, not least for forcing me to think more deeply about the 
issues involved.

-- 
Lew

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.gui

csiph-web