Re: [projects-dev] Access to Java module classes will be restriced

Svatopluk Dedic wrote:
> Tor Norbye wrote:
>> On Mon, 2003-01-06 at 02:16, Svatopluk Dedic wrote:
>>
>> Ok, speaking up:
>> would you mind replying to
>>   http://java.netbeans.org/servlets/ReadMsg?msgId=435428&listName=dev
> 
> (1) correct answer for short-term (other stuff to do) -- but incorrect 
> for IDE usability.
> 
> (4) there's nothing like "hidden" API. I would like to disallow access 
> to non-API classes eventually.
> 
> (5) Ugh. We already had a monolithic Editor and Java module is fat 
> enough already to be broken into pieces.
> 
> Let (6) = (2) + (3). I think the code which mines data from the parser 
> should be fairly decoupled from TaskList APIs - since the data could be 
> used in various ways for analysis too.
> BTW I would advise to either make ParserError an abstract class, so it 
> can grow in the future, or have some dynamic extensibility feature on it.
> 
> Anyway, I do not believe I have time for that :-\ I have already have my 
> friday project.

If you read (3) carefully you'll see that I've volunteered to do
the work myself.

So - is it acceptable to you if the java module API is enhanced
in the following way:
   JavaEditor - provides
      public void addErrorListener(ParseErrorListener listener)
      public void removeErrorListener(ParseErrorListener listener)
      public ParseError[] getParseErrors()
    new interface:
      ParseErrorListener {
          void errorsChanged()
      }
    new abstract class:
      ParserError
         has most of the methods found in current ParserAnnotation
    new private class:
      ParserErrorIpml extends ParserError
         its constructor takes a ParserAnnotation object
         and all its methods delegate to the ParserAnnotation
         object (getLine, getColumn, etc.)

In addition, in the two or three places where the list
of ParserAnnotations is modified, a check for
errorListeners != null is made, and if non null, errorsChanged()
on each is called.

While I agree there are no "hidden" APIs, you can mark these
methods @deprecated to discourage their use and indicate that
you don't not plan to support them forever. Once you get time
and interest in providing public API (org.netbeans.api) support
for these errors, I'll gladly update the tasklist modules.


This solution
- has an Abstract class as the ParseError "interface", so
   methods can be added later without problems
- Means only a couple of additional (small) classes in the
   java module
- Means almost no additional runtime overhead (just a null
   check in the places where error parsing has occurred)
- Means no work for you because I will do it. I can even commit
   the sources directly to the java module if you want (since
   I still have comit privileges after my projects work) but
   I assume you want to review the patches first so don't worry,
   I will never putback anything without explicit approval.

Sorry for being such a pest, but I have some loyal users of
this feature (myself included) and the current situation
(a fork of the java module, in the form of a patch provided
in the tasklist CVS module) seems much worse than the
alternative above.

-- Tor