Re: File browser
Daniele Futtorovic wrote:
On 2008-02-06 03:56 +0100, Lew allegedly wrote:
Daniele Futtorovic wrote:
And that's not even a "MUST" rule, but rather a strong recommendation
and its scope solely synchronisation/concurrency issues.
It is a "MUST" rule,
Some Swing component methods are labelled "thread safe" in the API
specification; these can be safely invoked from any thread. All other
Swing component methods
must
be invoked from the event dispatch thread.
/op. cit./
But not "must" in the sense that it strictly will not work if you don't
(synchronisation issues aside), is it?
I intended that in contrast to what Peter wrote:
I'm familiar with the issues relating to using GUI objects on a thread
other than where they are created, having a fair amount of experience
writing to both the Windows and Mac OS API, both of which are very
strict about making sure you create the object on the same thread
where the message pump for the object will be run (for example, on
Windows you won't even get messages for a given window instance except
on the thread where that window was created, so you must always have a
message pump on the thread where the object was created, and the OS
will always marshal calls to the window procedure
across to the correct thread).
It's not /that/ kind of a "must". Not as in e.g.: a statement MUST end
with a semi-colon. "Strong recommendation", as I put it, might be too
weak and I agree that for all practical purposes, it's a "must". But not
/sensu strictu/.
I guess it's like the old dentist's riddle: "Which teeth do I have to brush?"
"Just the ones you want to keep."
The tutorial says, "must". I just quoted it. I guess whether you regard that
as "merely" a recommendation depends on whether you want your code to work.
Me, I'm shocked at how hard people resist making programs more maintainable,
and spend many ergs arguing how less safe idioms are actually acceptable. I
guess they never had to maintain software themselves, or they'd come down a
lot more on the side of *good* practices and *safer* programming idioms.
But hey, argue all you want for unsafe, buggy code idioms. Go for it. Just
don't write any software I have to use, please.
--
Lew