Description Adrian Colyer 2004-03-16 05:03:02 EST

(From Wes...)

Since you're looking at this now, a step back might help,
for now or later...

It seems like IMessage is not perfect for handling some kinds
of messages we have:

- error line and defining declare error or warning
- one of many conflicting member declarations
- (Do any xlint warnings have different structures?)
- info from weaver?

We're augmenting it by kind (WEAVER_INFO?) and appendage
(details, extra source location...), so it is starting to smell.
(Details appears vestigial.  Extra source location has no context
for why it is being appended.)

One way to work around this now is instead to have different
IMessage implementations (e.g., DeclaredMessage, XLintMessage,
ConflictMessage, subclassing Message or EclipseMessage(?)).
Further, we might want an ISourceLocation implementation
"BinaryLocation" for sources in jar files.  (It might even
take on responsibility for pulling associated text from
a source path or src.zip.)

Doing this means that clients of IMessage and ISourceLocation
continue to work, but clients that know about BinaryLocation
and DeclareMessage, etc. can tailor accordingly.  This change
is nice b/c we don't change anything about how we handle messages
per se, and changing to subtypes should make sense in the context
they are being generated.  We can even have a "normal" message
subtype and audit away direct (non-testing) uses of Message.

Two unanswered and deferred questions:

(1) Whether we can continue to generate each message incrementally
but easily gather all associated messsages (deow, conflicts).
to facilitate message-handling strategies that group related
messages.  [defer until needed by client/strategy]

(2) Whether we should delegate to the smarter types for their
command-line renderings or keep using a renderer. [defer until
need renderer-less rendering]