Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » IMP » Proposed API change to IMessageHandler
Proposed API change to IMessageHandler [message #554928] Tue, 24 August 2010 18:46 Go to next message
Adam Taylor is currently offline Adam Taylor
Messages: 12
Registered: August 2010
Junior Member
*** Problem: ***

Quick Fix support:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=323532


*** Diagnosis: ***

For some quickfixes additional information is needed (an error code for example) when creating IMarkers and Annotations.


*** Proposed IMP API change: ***

Add the following method:

public interface IMessageHandler{
// ...

void handleSimpleMessage(String msg, int startOffset, int endOffset,
int startCol, int endCol,
int startLine, int endLine, Map<String, Object> attributeMap);

// ...
}

Also since this is a breaking change to this API, I suggest that IMessageHandlerExtension is thrown out and its method be added to IMessageHandler as well
Re: Proposed API change to IMessageHandler [message #554935 is a reply to message #554928] Tue, 24 August 2010 19:11 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi Adam

In my experience, functions with many arguments have many arguments
because there is a missing configuration/state object.

If you're breaking the API why not break it properly. Why are seven
attributes privileged while the rest are mapped? Surely severity,
source,... deserve to be privileged too? Why not allow derived
implementations to manage the representation to taste.

Generally at least one of startOffset or startLine/startCol is
redundant, ditto end... Putting them in the interface mandates that the
redundant one is calculated and that redundant state is propagated.

Regards

Ed Willink

On 24/08/2010 19:46, Adam Taylor wrote:
> *** Problem: ***
>
> Quick Fix support:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=323532
>
>
> *** Diagnosis: ***
>
> For some quickfixes additional information is needed (an error code for
> example) when creating IMarkers and Annotations.
>
> *** Proposed IMP API change: ***
>
> Add the following method:
>
> public interface IMessageHandler{
> // ...
>
> void handleSimpleMessage(String msg, int startOffset, int endOffset,
> int startCol, int endCol,
> int startLine, int endLine, Map<String, Object> attributeMap);
>
> // ...
> }
>
> Also since this is a breaking change to this API, I suggest that
> IMessageHandlerExtension is thrown out and its method be added to
> IMessageHandler as well
Re: Proposed API change to IMessageHandler [message #558305 is a reply to message #554935] Sat, 11 September 2010 00:00 Go to previous messageGo to next message
Robert M. Fuhrer is currently offline Robert M. Fuhrer
Messages: 294
Registered: July 2009
Senior Member
On 8/24/10 3:11 PM, Ed Willink wrote:
> Hi Adam
>
> In my experience, functions with many arguments have many arguments because there is a missing configuration/state object.
>
> If you're breaking the API why not break it properly. Why are seven attributes privileged while the rest are mapped?
> Surely severity, source,... deserve to be privileged too? Why not allow derived implementations to manage the
> representation to taste.
>
> Generally at least one of startOffset or startLine/startCol is redundant, ditto end... Putting them in the interface
> mandates that the redundant one is calculated and that redundant state is propagated.

Not so - not all of that info is redundant, and putting all of the attributes in a
map obscures the fact that omitting certain kinds of information disables key IDE
functionality. E.g., if one omits the line # info, the user can't double-click on
items in the Problems View and have the editor go to the correct line. Likewise,
if one omits offset information, the wrong range of text will get highlighted by
the editor annotation.

> On 24/08/2010 19:46, Adam Taylor wrote:
>> *** Problem: ***
>>
>> Quick Fix support:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=323532
>>
>>
>> *** Diagnosis: ***
>>
>> For some quickfixes additional information is needed (an error code for
>> example) when creating IMarkers and Annotations.
>>
>> *** Proposed IMP API change: ***
>>
>> Add the following method:
>>
>> public interface IMessageHandler{
>> // ...
>>
>> void handleSimpleMessage(String msg, int startOffset, int endOffset,
>> int startCol, int endCol,
>> int startLine, int endLine, Map<String, Object> attributeMap);
>>
>> // ...
>> }
>>
>> Also since this is a breaking change to this API, I suggest that
>> IMessageHandlerExtension is thrown out and its method be added to
>> IMessageHandler as well

--
Cheers,
-- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)
Re: Proposed API change to IMessageHandler [message #558359 is a reply to message #558305] Sat, 11 September 2010 15:53 Go to previous message
Robert M. Fuhrer is currently offline Robert M. Fuhrer
Messages: 294
Registered: July 2009
Senior Member
On 9/10/10 8:00 PM, Robert M. Fuhrer wrote:
> On 8/24/10 3:11 PM, Ed Willink wrote:
>> Hi Adam
>>
>> In my experience, functions with many arguments have many arguments because there is a missing configuration/state
>> object.
>>
>> If you're breaking the API why not break it properly. Why are seven attributes privileged while the rest are mapped?
>> Surely severity, source,... deserve to be privileged too? Why not allow derived implementations to manage the
>> representation to taste.
>>
>> Generally at least one of startOffset or startLine/startCol is redundant, ditto end... Putting them in the interface
>> mandates that the redundant one is calculated and that redundant state is propagated.
>
> Not so - not all of that info is redundant, and putting all of the attributes in a
> map obscures the fact that omitting certain kinds of information disables key IDE
> functionality. E.g., if one omits the line # info, the user can't double-click on
> items in the Problems View and have the editor go to the correct line. Likewise,
> if one omits offset information, the wrong range of text will get highlighted by
> the editor annotation.

To be more precise, at least the line # info isn't redundant since it can only be
calculated given something like an IDocument, which isn't available in the context
of an incremental project builder.

>> On 24/08/2010 19:46, Adam Taylor wrote:
>>> *** Problem: ***
>>>
>>> Quick Fix support:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=323532
>>>
>>>
>>> *** Diagnosis: ***
>>>
>>> For some quickfixes additional information is needed (an error code for
>>> example) when creating IMarkers and Annotations.
>>>
>>> *** Proposed IMP API change: ***
>>>
>>> Add the following method:
>>>
>>> public interface IMessageHandler{
>>> // ...
>>>
>>> void handleSimpleMessage(String msg, int startOffset, int endOffset,
>>> int startCol, int endCol,
>>> int startLine, int endLine, Map<String, Object> attributeMap);
>>>
>>> // ...
>>> }
>>>
>>> Also since this is a breaking change to this API, I suggest that
>>> IMessageHandlerExtension is thrown out and its method be added to
>>> IMessageHandler as well
>


--
Cheers,
-- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)
Re: Proposed API change to IMessageHandler [message #578123 is a reply to message #554935] Sat, 11 September 2010 00:00 Go to previous message
Robert M. Fuhrer is currently offline Robert M. Fuhrer
Messages: 294
Registered: July 2009
Senior Member
On 8/24/10 3:11 PM, Ed Willink wrote:
> Hi Adam
>
> In my experience, functions with many arguments have many arguments because there is a missing configuration/state object.
>
> If you're breaking the API why not break it properly. Why are seven attributes privileged while the rest are mapped?
> Surely severity, source,... deserve to be privileged too? Why not allow derived implementations to manage the
> representation to taste.
>
> Generally at least one of startOffset or startLine/startCol is redundant, ditto end... Putting them in the interface
> mandates that the redundant one is calculated and that redundant state is propagated.

Not so - not all of that info is redundant, and putting all of the attributes in a
map obscures the fact that omitting certain kinds of information disables key IDE
functionality. E.g., if one omits the line # info, the user can't double-click on
items in the Problems View and have the editor go to the correct line. Likewise,
if one omits offset information, the wrong range of text will get highlighted by
the editor annotation.

> On 24/08/2010 19:46, Adam Taylor wrote:
>> *** Problem: ***
>>
>> Quick Fix support:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=323532
>>
>>
>> *** Diagnosis: ***
>>
>> For some quickfixes additional information is needed (an error code for
>> example) when creating IMarkers and Annotations.
>>
>> *** Proposed IMP API change: ***
>>
>> Add the following method:
>>
>> public interface IMessageHandler{
>> // ...
>>
>> void handleSimpleMessage(String msg, int startOffset, int endOffset,
>> int startCol, int endCol,
>> int startLine, int endLine, Map<String, Object> attributeMap);
>>
>> // ...
>> }
>>
>> Also since this is a breaking change to this API, I suggest that
>> IMessageHandlerExtension is thrown out and its method be added to
>> IMessageHandler as well

--
Cheers,
-- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)
Re: Proposed API change to IMessageHandler [message #578159 is a reply to message #558305] Sat, 11 September 2010 15:53 Go to previous message
Robert M. Fuhrer is currently offline Robert M. Fuhrer
Messages: 294
Registered: July 2009
Senior Member
On 9/10/10 8:00 PM, Robert M. Fuhrer wrote:
> On 8/24/10 3:11 PM, Ed Willink wrote:
>> Hi Adam
>>
>> In my experience, functions with many arguments have many arguments because there is a missing configuration/state
>> object.
>>
>> If you're breaking the API why not break it properly. Why are seven attributes privileged while the rest are mapped?
>> Surely severity, source,... deserve to be privileged too? Why not allow derived implementations to manage the
>> representation to taste.
>>
>> Generally at least one of startOffset or startLine/startCol is redundant, ditto end... Putting them in the interface
>> mandates that the redundant one is calculated and that redundant state is propagated.
>
> Not so - not all of that info is redundant, and putting all of the attributes in a
> map obscures the fact that omitting certain kinds of information disables key IDE
> functionality. E.g., if one omits the line # info, the user can't double-click on
> items in the Problems View and have the editor go to the correct line. Likewise,
> if one omits offset information, the wrong range of text will get highlighted by
> the editor annotation.

To be more precise, at least the line # info isn't redundant since it can only be
calculated given something like an IDocument, which isn't available in the context
of an incremental project builder.

>> On 24/08/2010 19:46, Adam Taylor wrote:
>>> *** Problem: ***
>>>
>>> Quick Fix support:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=323532
>>>
>>>
>>> *** Diagnosis: ***
>>>
>>> For some quickfixes additional information is needed (an error code for
>>> example) when creating IMarkers and Annotations.
>>>
>>> *** Proposed IMP API change: ***
>>>
>>> Add the following method:
>>>
>>> public interface IMessageHandler{
>>> // ...
>>>
>>> void handleSimpleMessage(String msg, int startOffset, int endOffset,
>>> int startCol, int endCol,
>>> int startLine, int endLine, Map<String, Object> attributeMap);
>>>
>>> // ...
>>> }
>>>
>>> Also since this is a breaking change to this API, I suggest that
>>> IMessageHandlerExtension is thrown out and its method be added to
>>> IMessageHandler as well
>


--
Cheers,
-- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)
Previous Topic:Upcoming breaking API changes in the IMP runtime
Next Topic:Experiences; custom parser?
Goto Forum:
  


Current Time: Tue Sep 23 16:27:37 GMT 2014

Powered by FUDForum. Page generated in 0.02842 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software