Re: extended peers

[graydon hoare]

Sascha Brawer <address@hidden> writes:

> Brian Jones <address@hidden> 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