"John Keiser" <[EMAIL PROTECTED]> writes:
> If you're talking about minimizing the impact of field name changes, which
> is a separate issue, one way to do that is by introducing private
> constructors into Classpath, such as Class().
If the definition of a class has changed between the time an
application was compiled and the time it is run then it is reasonable
to throw an IncompatibleClassChangeError. I don't see what you're
getting at.
>From an OO perspective, there shouldn't be any direct accesses to
instance variables of a class such as Throwable.message since that
would make it painful for us (Classpath) to ever change that code. I
kept on reading and saw everyone apparently wants the same thing.
> String is the only one where there are strong dependencies on internal
> structure. You can probably get around these, but these are *strings*,
> probably the most-used class in Java (except for Object itself), and you
> need all the speed you can get.
Speed isn't the primary goal of Japhar or Classpath.
> I agree, Japhar *shouldn't* have to worry about field names in given
> classes--but it's the sad fact of the matter. I've minimized it any way I
> can.
I'll have to take your word for it. :) Back to working on the rest
of java.lang.*Error.java. Whee!
Brian
--
|-------------------------------|Software Engineer
|Brian Jones |[EMAIL PROTECTED]
|[EMAIL PROTECTED] |http://www.nortel.net
|http://www.classpath.org/ |------------------------------
