Sascha Brawer <[EMAIL PROTECTED]> writes: > Brian Jones <[EMAIL PROTECTED]> wrote on Fri, 12 Sep 2003 08:58:29 -0400: > > >What parts of our code would rely upon having a ClasspathToolkit > >with the additional Font related stuff? > > The JavaDoc of the enclosed classes "ClasspathToolkit" and > "ClasspathFontPeer" explains the expected uses. > > Would those two classes be suitable for eventual inclusion into Classpath? > > Graydon, would this FontPeer be ok, or would you like to see things done > differently?
In principle I like the direction, but I would make two changes to these interfaces: First, the font-related factory method on the toolkit should produce a ClasspathFontPeer, not a java.awt.Font. The factory method will be called *from* a java.awt.Font constructor in user code, thus has no opportunity to influence the identity of the Font object being constructed. Second, I think the ClasspathFontPeer should not be passed java.awt.Font objects as arguments to its methods. This practise implies an 'instanceof' operation, and (possibly failing) downcast on every operation, or at least some sort of hashtable lookup. Instead, I think the ClasspathFontPeer should hold state itself, or at least be the object identified with state (whether internal or external -- a singleton is still possible, just using static methods within a subclass keyed to the identity of the ClasspathFontPeer in question, not the Font). This approach is theoretically equivalent to yours, but saves the downcasting / hashing, and associated possibility of runtime failure. I figure a 1:1 relationship between Font and ClasspathFontPeer objects is likely anyways. Do you object to these suggestions? -graydon _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
