On 08/25/2009 06:32 PM, Oleg Sukhodolsky wrote:
you will need to specify all possible issues carefully, and, as far as
I remember,
writing such specification is a pain.
...
you need to specify correct behavior at least for JCK (but I suspect,
that users would like to have good specification too ;)
Also "more specification" == "harder to use".
Agreed. OTOH, no or little specification usually results in unsatisfied
over-optimistic expectations. :)
Regarding technical details, it is obvious that the set of "restricted"
calls depends on the style in question. So we could specify that the
behavior of UTILITY windows is undefined if a developer invokes any
focus-related methods on that window, and then list a few methods of
that kind to give examples (e.g. setWindowFocusableState()). This seems
to be quite enough to make both the JCK and the developers happy. We'll
review the specification proposal on this mailing list in a little while.
As possible resolution for the first issue we could use some factory
methods/classes.
That looks like a really bad idea to me. Just recall the number of
constructors the JDialog currently has... So I would like to avoid both
adding new parameters to constructors, and creating any factory
methods/classes.
It is really abstract question, but factory class is supposed to
minimize number of factory methods and ctors ;)
This is no different than specifying that a method may only be invoked
when the window is hidden (setUndecorated() comes to mind), or has not
yet been shown - like the pack() that is only meaningful before first
showing, etc. But adding simple methods creates less syntactic garbage
at least, and also enables to change some properties on the fly (even if
hiding the window is required).
--
best regards,
Anthony
